The Hidden Software Side of Risk in IoT Companion Apps

Minette Zongo Meyo -

I. Introduction

The internet of things (IoT) ecosystem is growing rapidly, with connected devices constantly rising and projected to reach 40 billion by 2030. IoT mobile applications, also referred to as IoT companion applications, are now embedded in every aspect of our daily lives. From smartwatches to fitness trackers at early use, to home automation, healthcare monitoring, and industrial control, these applications manage both personal data and important infrastructure.

IoT companion apps are desktop or mobile apps that enable users to interact with, monitor, and manage IoT devices via a UI –intermediary between device firmware, cloud services, and users. Their ubiquity and constant connection to the Internet provide benefits for individuals and organisations, but also come with major security concerns, often making them an easy target for attacks. In this blog which is a first to a series of IoT application security, we will discuss the hidden risks of IoT companion apps in a software standpoint, and provide ideas of how developers can minimize or eliminate these risks.

II. IoT Companion Apps Architecture and Hidden Risks

II.1 IoT Companion Apps Architecture

IoT companion apps are human-facing software on top of the IoT application protocol stack that employs protocols like HTTP, MQTT or proprietary APIs. IoT companion apps typically have three-tiered architecture:

  • The mobile front-end that controls operations and user interface;
  • The cloud back-end that manages storage, authentication, and APIs;
  • The device layer which has to do with sensor data and execution of instructions.

This layered architecture is meant to ensure strict security boundaries, but as it is now, developers prioritize speed of release over hardening security. And so, while serving as essential intermediaries, they often become significant security liabilities due to potential architectural deficiencies.

II.2 IoT Companion Apps Hidden Risks
This privileged position of IoT companion apps as a bridge between users and IoT devices makes them a prime attack target. In fact, if compromised, attackers can gain access not only to the application itself but also to the connected devices and underlying broader network. Some concrete risks in IoT companion apps architecture include:

  • Insecure communication: companion apps frequently fail in to properly encrypt communications. So, many apps fail to provide secure transport due to the reuse of existing apps structures, leaving APIs open to man-in-the-middle attacks. Actually, roughly half of these applications lack adequate encryption, and more than 40% allow unverified connections, creating exposure to man-in-the-middle attacks as well.
  • Hardcoded credentials and tokens: embedded keys, API tokens, or credentials in app binaries are easily extracted via reverse engineering, granting attackers unauthorized access to back-end sensitive data.
  • Outdated components and vulnerable dependencies: till date, many apps still depend on deprecated librairies that contain know vulnerabilities; e.g., older versions of OpenSSL which are an open door to attackers.
  • Insecure data storage: sensitive data such as health log, is sometimes configured to be stored in plaintext on devices.

In view of the above, we are gathered a few advices to developers to follow when designing and IoT companion apps

III. The developer's guide to IoT companion app security: where to focus your efforts:

To tighten companion security, these are some ideas on how developers can rigorously limit or eliminate the risks associated to IoT companion apps: rigor and integrate them into testing workflows:

  • Building a digital fortress by encrypting and securing communication, keeping in mind that IoT devices have capacity constraints and lightweight solutions must be prioritized. For example, thinking about securing CoAP or MQTT with Datagram Transport Layer Security (DTLS) is a viable option.
  • Protecting the key to your app, with secret encryption and robust authentication. For example, embedding credentials in the code must be banned and strong authentication mechanism can be incorporating token rotation capabilities in authentication mechanisms.
  • Maintaining a secure supply chain, by managing dependencies. One solution to this can be implement dependency scanning tools as part of the regular development workflows to automatically detect outdated or vulnerable libraries before they can be exploited.
  • Implementing the digital minimalism paradigm by setting up secure configuration and permissions. Here we thought of establishing as permission management principle, the least privilege that requests only the minimum device permission necessary for core functionalities.

IV. Conclusion

In this blog, we raised an awareness on the risks associated with IoT companion apps in our daily lives. We focused on the software part of the risks by pointing out some concrete risks in IoT companion apps architecture. We ended by providing directions to IoT companion apps developers in how they can reduce or eradicate those risks. In our next blog, we will present a use case of a specific risk that is more and more recurrent in IoT companion apps.  

References:

  1. Image by creativeart on Freepik
  2. Preliminary results of my ongoing study.