From August 2024, the EU Radio Equipment Directive, or RED for short, will require the majority of all devices with a radio data link to be more cyber-secure. Devices capable of radio communication must not endanger or restrict the operation of a network; instead, they must actively protect personal data and counteract fraud. In fact, update capability will be a must. However, the method is not predetermined, so manual solutions such as USB sticks are also conceivable. For practical reasons, however, over-the-air (OTA) updates via existing or newly created cloud portals are likely to prevail, at least if the wireless technology used offers sufficient bandwidth. Either way, update capability will become a basic requirement for CE marking - with all the consequences that entails.

Time to act

Even if details will probably not be announced until the end of the year, providers of devices that fall under the RED should therefore react quickly. A sensible first step is to check their own products for conformity with existing standards such as ETSI EN 303 645 (consumer products) or IEC 62443 (industrial products) and adapt them if necessary. The RED refers to these standards, which many experts believe are the likely basis for future harmonized specifications. There is also much to suggest that end customers, as device operators, will demand compliance with these standards: After all, interest in cybersecurity is growing due to an increasing number of hacker attacks.

For those responsible for embedded developments - whether in development or product management - it is worth taking a look at both standards, as many of the regulations for industrial and consumer products can also be applied to embedded security. However, the risk-based approach of IE 6244 deserves particular attention. The security mechanisms of this standard build on each other like layers: If one layer is compromised, the subsequent one takes effect. The aim of this approach is to gradually reduce the attack surface. However, as this can only be implemented to a limited extent in practice, a systematic approach to the topic of embedded security is advisable.

Systematically to safety

Embedded security includes all tools, processes and best practices for protecting the software and hardware of embedded devices. A secure embedded system is therefore characterized by the following features:

Container software is also dependent on access to the system and hardware input data. Application and system developers must therefore pull together for a holistic security concept.

© Grossenbacher systems

• Trusted Execution Environment (TEE), also known as TrustZone in the ARM environment: Only specially enabled applications can be executed in a TEE, but no hacker programs, for example, which by their very nature do not have the necessary enabling.
• Partitioned hardware resources: Separation of CPU, cache, memory and interfaces in order to provide their functions as independently and separately as possible. This enables mutual protection in the event of errors.
• Memory blocking: Executable space protection explicitly marks certain memory areas as not legally usable. Misuse triggers an alarm or countermeasures, preventing unwanted hacker code from finding a place.
• Secure Boot: Every embedded device boots in a similar way to a PC and searches for its smallest start-up program (boot), in which the correct start-up process, including the applications to be started and their sequence, is defined. Manipulation at this point would allow the entire device to be misused. With the Secure Boot feature, the boot program is checked using cryptographic algorithms at every start.
• Protection of stored data (Protect Data at Rest): This includes application data, configuration data, security keys, but also usernames, user rights and passwords. These must be explicitly encrypted and should be protected, encrypted and stored in special security hardware available in the controller.

Recognize and eliminate weak points

An analysis of frequently occurring vulnerabilities in the software is also helpful in the development of secure embedded systems - five points come to mind here, the first of which is particularly critical: