SECURE INTERNET OF THINGS (IOT) FIRMWARE UPGRADES IN A WIRELESS NETWORK

Internet of Things (IoT) devices/sensors/endpoints (collectively and generally IoT devices) are becoming part and parcel of many establishments. With the inbuilt support for Wi-Fi 6, also known as “AX Wi-Fi" or "802.11ax Wi-Fi,” in many IoT devices, the number of deployed IoT devices will continue grow. Wi-Fi® is trademark of the Wi-Fi Alliance. These IoT devices come from various manufacturers and will require network/Internet access for firmware upgrades. As such, there is a need to create a secure and tested firmware upgrade environment for such devices. Presented herein are techniques to track the firmware of IoT devices and use Manufacturer Usage Descriptions (MUD) to recognize the recommended firmware and settings. Further, the techniques presented herein include a mechanism to optimize firmware upgrades using Target Wake Time (TWT) scheduling. DETAILED DESCRIPTION It is expected that, within the next two years, more than twenty (20) billion IoT devices will be network connected. In particularly, it is expected that more and more enterprises and industries will onboard IoT devices, such as cameras, Smart Lights, sensors, etc., and that most of these devices will connect over various wireless networks. With WiFi 6, large amounts of devices can connect and be spread across a large geographic area (large cells and multiple cells). Additionally, with Uplink Orthogonal Division Multiple Access (UL OFDMA) capabilities in Wi-Fi 6, access points are able to sustain a much greater number of active associations, relative to previous versions of Wi-Fi (e.g., up to 4K endpoints may be associated to a single 11ax access point, and the protocol was designed to allow for that 2 Saini et al.: SECURE INTERNET OF THINGS (IOT) FIRMWARE UPGRADES IN A WIRELESS Published by Technical Disclosure Commons, 2019 2 5871X many active clients). The IoT devices can be deployed across large areas (like smart cities) and in networks with reduced or no direct connectivity to the Internet. Ensuring that all deployed IoT devices run the most update to date firmware is mandatory to avoid, for example, potential security attacks. However, such update logic comes with various challenges, such as: 1. How to identify the availability of firmware; 2. How to distribute upgrades in a safe and secure manner to a large number of endpoints; and 3. How to validate that the new firmware is valid (authentic) and is not causing issues. In a pull model (where IoT devices contact an update server at regular intervals), the attack surface is wide (e.g., between the discovery of a new exploit and the next updatepull cycle, a large number of clients may be exposed). In a push model (where a server pushes the update to the individual clients), Man-in-the Middle (MItM) attacks are possible and, as such, fake firmware may be distributed to clients. In both the push and pull models, the requirement to 'keep the pipe open' between all clients and all possible update servers makes large scale management impossible. Presented herein are techniques to address the above challenges by combining novel MUD and Wi-FI 6 capabilities in complementary ways. MUD is well-known, but has conventionally been intended to carry policy information. In contrast, the techniques presented herein extend MUD intent by allowing it to carry implementation and state information (e.g., about the device, the firmware it runs, device needs, the tolerance to delay, the change of behavior after upgrade, etc.). The concepts of IoT firmware updates and the updating of large quantity of devices have been explored. However, Wi-Fi 6 devices present specific constraints and optimization opportunities that have not been explored yet, and that are specifically addressed by the techniques presented herein. 3 Defensive Publications Series, Art. 2477 [2019] https://www.tdcommons.org/dpubs_series/2477 3 5871X Background: The updating firmware on IoT devices requires the following:  Identifying if there is an update for the IoT device and assessing its criticality (e.g,. is it a security patch or just a feature update).  Accessing the verified copy of the firmware update.  Distributing the firmware in an efficient manner and quickly ensuring devices are awake and ready to process the image when they are ready to go. In the world of IoT, there are two main models to fulfil the above requirements:  In a pull model, the IoT device attempts to connect to update servers at regular intervals. This model is problematic for emergency or security updates (as the device may not attempt the update until its next update pull cycle).  In a push model, the management platform can initiate an update at any time when the IoT device is awake and connected. A limitation of this model, for emergency updates, is that the vendor may need to update 'now' 'all' devices on the planet, which presents obvious scalability issues (and it is difficult to explain to a customer that their IoT device was compromised because it was lower on the list of devices to update urgently, as other customers were 'more important'). Both of the push and pull models also suffer from the device update orchestration problem. The server can know which devices have been updated, but does not know when non-updated devices are going to update next (in a pull model), or why they haven't been updated yet (in push/pull models where IoT devices are unreachable by the server). Similarly, local OT management systems may know which devices have received an update, but network elements do not have that knowledge, thus potentially allowing unsafe devices to continue operating without the required update. For example, in 2017, five Nissan Renault factories were crippled due to the Wannacry ransomware attack which 4 Saini et al.: SECURE INTERNET OF THINGS (IOT) FIRMWARE UPGRADES IN A WIRELESS Published by Technical Disclosure Commons, 2019 4 5871X froze HMI workstations on their factory floor. These were HMI stations running older, unpatched versions of Windows in their industrial automation system. The techniques presented herein addresses this issue, especially in the context of 802.11ax environments, as an illustration of the method in wireless environments where data exchange can be scheduled. Acquiring Information about Device Firmware Update: In the examples presented herein, each object is associated to an object group that the group documents the object type. Additionally, every IoT device adhering to the MUD architecture must send a URI after every reboot and ask for a new MUD file. This is proxied via the MUD controller. This URI can be cached for a group of IoT devices (Grouping of IoT devices based on MUD is prior art). The techniques presented propose an enhancement to the MUD exchange with several additional elements which take into account 11ax devices. First, the MUD URI is augmented to include the current firmware version. This is an extension to RFC 8520, but is different from the current art. RFC 8520 allows the URI to contain in the identifier of the MUD file a path that can indicate the firmware version requested by the IoT device (e.g., myvendor.com/object/v43/file or myvendor.com/object/filev43). As the MUD URI is hard coded in the device, this provision forces the vendor to install, in that location, a new version of the firmware (e.g. v44) when updates are needed, which creates complexity. In the techniques presented herein, the version of the firmware is appended to the MUD URI, separated by a wellknown special character (e.g., myvendor.com/object/filev43). This information is stripped by the MUD controller and retained for future use. Other embodiments may provide the firmware version in a different structure, such as: an 802.11 IE at association time or in a null frame; a second frame following the MUD URI, etc. In all cases, the firmware version is obtained along with the MUD file, but does not reflect the version that the IoT device is attempting to obtain, but rather the version that the IoT device is currently running. 5 Defensive Publications Series, Art. 2477 [2019] https://www.tdcommons.org/dpubs_series/2477 5 5871X Next, the MUD file returned by the vendor includes several new components. First, the MUD file returned by the vendor includes the current recommended firmware version, size, release date and criticality level. In the current art, the MUD file defines access rules, but not firmware versions. The techniques presented herein use MUD in a new way to carry this information and to indicate the manufacturer's recommenced firmware (and therefore configuration) state. As a result, the MUD controller has a record of the discrepancy. As such, MUD is no longer a policy tool, but instead becomes a tool to exchange state information (state of the device, mentioning its current firmware version in the request, expected state returned by the vendor). Second, the MUD file returned by the vendor includes the location of the server from where the firmware update can be obtained. Third, the MUD file returned by the vendor includes Wi-Fi6 delay tolerance and RU information, as per the below. The change of device behavior expected after the update is now addressed. In the context of the examples presented herein, the behavior describes the TWT and RU profile that will be used for the IoT device. It is noted that, in 802.11ax, IoT devices can conserve battery and only wake up at Target Wake Times. The IoT device can request a TWT interval from the AP. The AP also implements a scheduler and can override the IoT device requested TWT interval. It follows that an IoT device may send several types of traffic. As such, the IoT device may request TWTs matching the traffic type and configured communication interval. Depending on the traffic, delaying TWT (due to AP override) may be tolerable only to a certain delay value. The current art related to MUD describes access rules that the network elements can use to determine the IoT device's require