What does the EU Cyber Resilience Act (CRA) mean for connected device manufacturers?

We recently published a blog post about the impact of the Cyber Resilience Act (CRA) for mobile applications: Cyber Resilience Act: what it means for Mobile Application Security.

In case you have no time to read, the Cyber Resilience Act is a new legislation proposed by the European Commission to improve the cybersecurity posture of organisations using digital assets. The act seeks to ensure that companies have the necessary policies, procedures, and technologies in place to protect themselves and their customers from cyber threats. This is in response to the increasing number and cost of successful cyberattacks, which were estimated to cause annual global costs of €5.5 trillion in 2021.

The legislation aims to set common cybersecurity regulations for manufacturers and developers of products with digital elements in the EU market. The act is one-of-a-kind and testifies to the European Commission's analysis that cyber risks are a matter of social, political, and economical importance. Currently, there is no coherent cybersecurity standard for all products leveraging digital assets within the EU market, and the CRA aims to rectify this state of play.

CRA concerns any connected device deployed in the field, either for consumer or professional purpose. Depending on their nature, the device manufacturers will have to:

• either do a self-assessment of their product (default category),
• or make self-testing (critical Class I),
• or go through a certification lab (critical Class II).

Source: The European Cyber Resilience Act (CRA)

What will the OEM have to do to get ready for CRA?

Consider defense in-depth

To answer this question, let’s go back to the concept of defense in depth. For those who are not familiar with it, defense in depth means that security is implemented at every layer of the product. A layer can be :

• the hardware (e.g. a chip embedding cryptographic assets), the low-level firmware or component (e.g. a bootloader),
• the low-level firmware or component (e.g. a bootloader),
• the operating system (Linux),
• the application software or library (e.g. a network protocol stack, a trustlet, a white box cryptography library), or
• the service (e.g. connection to a back-end server).

Integrate security testing

To start from a solid basis, device manufacturers will have to preferably select hardware and software that are individually compliant with the CRA rules. But it will not be enough, because, as they integrate and possibly modify different hardware and software components in their device, as well as their own code, they could by mistake or ignorance (e.g. no implementation guidelines provided by the supplier for security) introduce vulnerabilities in the overall system. This could happen at the product launch but also during a firmware upgrade.

An immediate consequence of this is the device manufacturers will have to put in place a security policy or reinforce it to turn their product development cycle into a secure product development cycle, which will mainly imply to:

1. A- Identify and track assets stored in and manipulated by the device.
2. B- Apply the security guidelines provided by their suppliers, if any, when integrating their components into the device.
3. C- Monitor the hardware and software Common Vulnerabilities and Exposures (CVE) of the components they integrate from MITRE.
4. D- Test the critical functions (from a security standpoint) manipulating or giving access to the assets of the device.

Testing critical functions on the actual device might not be easy though.

A security test example from the ARM PSA certification scheme

Let’s take an example from the PSA (Platform Security Architecture) certification scheme that may be well known from the IoT industry: the test case from the PSA Certified™ Attack Methods Version 1.2 named “Glitch against initialization”.

The purpose of this test is to check that the Device Under Test (DUT) is not sensitive to a perturbation (called glitch) applied to an I/O of the chip during the boot and device initialization process. This technique can be used by attackers to disturb this critical phase and get unexpected behaviour like skipping the firmware signature check and running a rogue firmware giving the attacker privileges to control the device.

How can the product manufacturer make sure that this “Glitch against initialization” test is passed on their device? We may reasonably think (and definitely verify) this test has been performed and passed by the chipset maker. But, what if modifications made in or around the bootloader unexpectedly change the device behaviour and introduce a vulnerability? The only way to figure it out is to test.

Testing protections in a product is a difficult task. Indeed, most protections do not have any functional impact. They act in the background in case something malevolent happens. We could say they are “transparent”. They require a specific testing environment mimicking the attacks to trigger the protections and execute the corresponding code. This is the case for our glitch scenario. Furthermore most of the product manufacturers do not have a glitching setup to perform such a test and may even never heard about it. This is absolutely normal.

Focus on what you have to test

Anyway the good news is they do not need all this, because they do not aim at testing the chip the firmware is executed on (we said it has been done by the chipset maker). Their goal is only to test that the modifications they made in the firmware provided with the chip have induced no regression in this glitching test.

You touch the software so work in an emulation environment

A test tool like esFirmware that provides an emulation environment where to execute a piece of firmware, knowledge about the “Glitch against initialization” test, and a practical use case, allows the manufacturer to test, minimise the risk and show confidence without the burden of investing into a large amount of expertise and time to perform just a single test case.

All that has been said about this glitching test case is just an example to illustrate what is at stake. It can be extended to many other attacks that need to be tested on the final production device to avoid the introduction of any security regression during the development cycle.

What will the OEM have to do to get ready for CRA (again)?

1. A- Figure out what are the threats the connected devices are exposed to.
2. B- Understand the attack paths.
3. C- Perform security non-regression testing.

Pave the way for more and better security with proper tools and knowledge centres.

As new rules will be enforced by the CRA, anticipating and starting now might not be a bad idea.