Far Far Edge: The opportunities and challenges

• Cloud
• Confiance
• Cybersecurity
• IoT
• sécurité et transactions

Share on Twitter : Far Far Edge: The opportunities and challenges (New window) Share on Linkedin : Far Far Edge: The opportunities and challenges (New window)

What is Far Far Edge?

Edge computing is primarily aimed at hosting applications on compute nodes that are generally classified according to their distance from their customers. Therefore, we can distinguish between cloud nodes, located in centralised cloud data centres; edge nodes, located in the carrier’s access network infrastructure; far edge nodes at the edge of a network, such as Wi-Fi boxes; and finally, far far edge nodes that are directly on connected objects, typically on microcontrollers (A microcontroller is a small computer integrated into a circuit that controls electronic devices. It performs specific tasks, such as managing sensors or motors, and is often used in devices such as household appliances, toys or security systems).

The Far Far Edge paradigm is characterised by the ability to deploy code directly onto microcontrollers, often in the form of containers. This approach allows for greater flexibility, as multiple applications can coexist on a single device, making it easier to integrate different features and new players using these features. However, this greater flexibility brings with it significant challenges, including security, resource management and intellectual property protection.

Imagine that a company that produces standardised containers for sea, rail or road freight decides to create a new product, “SmartDroneBox”, a box specifically designed for drone delivery and equipped with a logic to ensure that its contents remain intact. The SmartDroneBox provider decides to add value to it by allowing third parties to run code on it. For example, it could be code specific to the delivery company, enabling it to display the recipient’s address and collect their signature, or to monitor and verify compliance with certain delivery conditions such as orientation, temperature and humidity. It could also be code deployed by a third party who is not involved in the delivery service, wishing to map the radio coverage of a city.

Figure 1. Example illustrating far far edge — SmartDroneBox

Running containers on microcontrollers is possible…

Thanks to Docker, it is already possible to extend the cloud to the edge of the network, as Docker requires 4 gigabytes of RAM, which corresponds to a Raspberry Pi 4. However, to go any further, you must be able to deploy containers on more constrained connected devices that typically have microcontrollers with only a few tens or hundreds of kilobytes of RAM.

Figure 2. Overview of the capabilities of connected devices and containerisation solutions

Several solutions enable the creation of isolated execution environments for containers on microcontrollers. They are divided into four main families, characterised by isolation method, software or hardware, and the type of instructions transmitted, whether understood by humans or precompiled machine code. Among these solutions, Orange has specifically investigated Pip-MPU solutions (a formally verified open-source kernel designed by Orange in collaboration with the University of Lille), WebAssembly (abbreviated Wasm, a W3C standard that defines an instruction format for an isolated execution environment) and rBPF, a lightweight and microcontroller-friendly version of eBPF, a technology that enables kernel-mode code execution in the Linux operating system.

Figure 3. Some solutions that let you run containers on microcontrollers.

…but there are still some challenges…

While containers can be run on embedded systems, there are not many solutions for deploying and managing their life cycles on microcontrollers, as options such as Kubernetes and wasmCloud are not suited to these devices’ memory constraints. To our knowledge, the only solution that existed before the TinyPART project is limited to the development of non-standardised containers on ESP32 microcontrollers, without the ability to create services made up of multiple containers. In addition, the flexibility offered by containers could potentially expose resources to attacks, allowing attackers to exploit vulnerabilities using denial of sustainability (increasing power consumption), denial of quality (modifying the technical parameters of industrial robots) and the “Dead Man’s PLC” (controlling equipment via clandestine networks with ransom demands), among other attacks.

Figure 4. New threats posed by containerisation

…which the TinyPART project is responding to

The TinyPART project meets the security and privacy protection objectives in two ways. The first aims to enhance isolation while maintaining flexible properties. The second is container life cycle management and precise control of access to resources.

Enhancing isolation with Pip-MPU

The University of Lille and Orange joined forces to create Pip-MPU, a kernel that relies on a hardware MPU (Memory Protection Unit) to ensure strict separation in terms of confidentiality and integrity between different executable components organised in the form of partition trees.

Enhanced security for updates with SUIT

To enable secure updates to portions of code from different players within the firmware publisher, which is the case when updating or deploying containers, Inria (Institut national de recherche en sciences et technologies du numérique — the French National Institute for Research in Digital Science and Technology) has implemented and adapted the IETF SUIT protocol in RIOT.

Life cycle and resource access management with TinyContainer-as-a-Service

TinyContainer-as-a-Service consists of three levels of tools developed by Orange. The first is the TinyContainer agent, an open-source module embedded in connected devices that manages the container life cycle and access to local and remote resources, while using manifests to enforce an access control policy. The second level is the TinyContainer Edge gateway, which links protocols optimised for connected systems to traditional web protocols. Finally, the TinyContainer-as-a-Service platform lets different stakeholders manage connected devices and containers.

Figure 5.  Components of TinyContainer-as-a-Service

These results are a step towards the SD-IoT (Software-defined Internet of Things) paradigm, allowing remote programming of connected devices, thus facilitating rapid adaptation to user needs.

Figure 6. SD-IoT paradigm

What is the added value?

The main advantage for customers is the flexibility to deploy code on connected devices without changing the entire firmware or restarting the device. We can identify three use case families:

1. Mass customisation: Allows users to customise products, such as setting up a sports session on a connected device in a smart city or customising a microwave’s interface to display the most used controls.
2. Firmware variations control: In sectors such as Industry 4.0, adapting the operation of equipment to specific contexts is essential. Instead of managing multiple versions of firmware in parallel, it will be possible to create basic firmware containing stable functions and put context-dependent functions in containers. Containerisation will reduce time spent, development cost and complexity of maintenance and of CRA compliance monitoring.
3. Third-party code deployment: Users can choose to modify their connected devices using third-party applications from a marketplace. Another example is allowing a subcontractor to deploy maintenance logic on industrial equipment. It is also possible for owners of connected devices to generate additional revenue by renting the resources of this equipment to other players, as illustrated in the SmartDroneBox example presented in the introduction. Containers facilitate this flexibility while ensuring isolation and security between different players.

Figure 7. Use case families of microcontroller container

Conclusion and possibilities

In conclusion, the work around the far far edge paradigm and the TinyPART project is promising for the future of embedded systems and edge computing. One of the major challenges is creating a new infrastructure operator model, where, unlike traditional cloud solutions, we could operate third-party resources. This innovative model would connect players wishing to execute code on the resources of these third parties, promoting dynamic collaboration and optimal use of available capacities. By facilitating access to a variety of resources and ensuring security and flexibility, we could transform the way applications are deployed and managed, while meeting users’ specific needs in an increasingly connected ecosystem. This approach could not only improve operational efficiency, but also drive innovation in various sectors, making edge computing technologies more accessible and relevant.