Cybersecurity and embedded defence systems

A constrained world

Embedded systems, particularly in the aeronautical and military sectors, are subject to a number of constraints that must be taken into account in the design of cybersecurity systems. First of all, there are physical constraints – weight, size, temperature, etc. – which drastically limit the field of possibilities. Added to this, there are energy consumption constraints with the sovereign aim of increasing the aircraft’s autonomy as much as possible, for which a few extra minutes of flight can make all the difference. This quest for the lowest energy consumption also creates other constraints, such as memory capacity. In order to minimise the losses caused by successive voltage conversions, specific power supply cards are also sometimes created, whose efficiency requires that a certain energy package be scrupulously respected, which is another constraint!

It is also essential to consider the notion of real-time processing for an onboard defence system. This requirement, related to the operational availability of the system and the entire platform, is crucial given the criticality of the events managed during a mission. It is therefore unacceptable for the triggering of an antivirus to disrupt real-time processing and the reliability and accuracy of the data processed.

Cybersecurity tools are not exempt from operational constraints either. For example, the time required to perform a check can extend the time required to turn on or start up the onboard system and consequently the aircraft. If the system is critical to the success of the mission, a trade-off must be made between safety requirements and operational availability. The same is true for the emergency shutdown, launched when the system could end up in the wrong hands, where a balance must be found between the efficiency of the operation and its duration.

Finally, the choice of components is itself limited. On the one hand, there is very little cybersecurity software developed specifically to meet the requirements of embedded defence systems. On the other hand, the functionalities provided by these tools for embedded defence are subject to export restrictions, which may contraindicate their implementation in a system. Depending on the case, these may be outright bans (e.g., imposed by the U.S. ITAR regulations) or conditional authorisations (e.g., a limited number of units). Often, these limitations prevent the use of components dedicated to cryptography, which forces the implementation of encryption modules on general-purpose processors, which thus use up some of their power.

Anticipation, ingenuity, rigor

In short, obtaining the required level of security while minimising power consumption is like squaring the circle. To solve it, it is crucial to take cybersecurity into account upstream, right from the system specification stages, because it will then be very difficult – if not impossible – to insert new requirements into a set optimised for so many interdependent constraints. You have to ask yourself what the risks are, what level of protection you are aiming for and what components are suitable for this.

From there, development is a matter of anticipation, ingenuity and rigor. Anticipation of all the requirements within the limits of an acceptable risk. Ingenuity to find ways to guarantee safety without losing performance. Rigor, finally, when it comes to minimising the size of the code, checking the absence of dead code (superfluous remnants of development and sources of vulnerability), or applying good coding practices that allow both to limit risks and optimise performance.

Find the right balance

The challenge is not just to allocate computing power, but also to reconcile the various security and operational requirements, while taking into account the various environmental constraints of the embedded system. This is a complex triptych, which requires a 360° control of the system, the platform in which it will be embedded, and the broader environment in which it will evolve.

This challenge, whether operational, technological or safety-related, is manageable as long as the parties involved (the platform manufacturer, the safety approval authority and the embedded system manufacturer) discuss and agree on the system’s priorities. Anticipation, convergence and collaboration are the key words.