Do Products Need to Implement Secure Boot in Order to Achieve CRA Compliance?

A tricky question...

This is a difficult question to answer, because while the CRA says (in Annex I Part I (2)):

On the basis of the cybersecurity risk assessment referred to in Article 13(2) and where applicable, products with digital elements shall:

(f) protect the integrity of stored … commands, programs and configuration…

…it doesn’t actually mention secure boot. But then, it’s a regulation, not a standard, so it wouldn’t usually be expected to include any form of technical advice as to how to meet its provisions.

Because there is not yet a CRA-corresponding Harmonised Standard (see below), we have – on one hand - to rely on various sources of interpretation and opinion to come to a view as to whether and how to protect the integrity of programs and data. On the other hand, it’s also true that even if it’s clear that secure boot is the only realistic way to achieve that protection, the protection requirement itself is, along with most of the CRA’s provisions, qualified by the findings of the cybersecurity risk assessment.

Protecting the Integrity of Programs and Data

On the first point, let’s look at the environment in which integrity is to be protected.

You might perhaps consider the firmware to be inaccessible. However, this cannot usually be the case. To be within scope of CRA in the first place, the device must be one which “includes a direct or indirect logical or physical data connection to a device or network". In addition, the CRA places an obligation on manufacturers to check continually for vulnerabilities, and “provide for mechanisms to securely distribute updates”, and ensure that where vulnerabilities are to be addressed, those updates are disseminated in a timely manner and free of charge. (Annex I Part II 7, 8).

The secure distribution of updates has a bearing on the question of secure boot, since firmware which is open to updating must be vulnerable. Authentication underpinned by a local, immutable root-of-trust provides the most obvious, effective and straightforward means to ensure that the pre- and post-update firmware is as intended, and no unauthorised update can be performed. Another consideration here is that especially around mechanics of updating, secure boot must not provide in itself an opportunity for an attacker, or indeed some sort of bug, to disable the device, thereby succeeding in taking the system out of service. Therefore a failed attempt to authenticate firmware must not result in the unit being “bricked”. The CRA itself mandates an option to return the unit to factory settings, and it should be possible for a well-designed update process to always revert to the former good image if an updated image fails authentication.

So if we have connectivity, and particularly if we have updates, we should have secure boot in all “usual” scenarios because the firmware is exposed. But of course just like the requirement to protect the integrity of firmware, the requirement to update is itself subject to the risk assessment.

Can the Risk Assessment Provide an Excuse?

Looking to the risk assessment then, can we ever argue that the requirement to ensure the integrity of programs and data need not apply?

Legally, it’s possible. In (Recital (55)) it’s stated that an essential cybersecurity requirement may be argued as not applicable to a product where “incompatible with the nature of a product with digital elements”. Also we have (Art.13.3) “The cybersecurity risk assessment shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements”.

So a particular requirement may be excluded, either through incompatibility or via a justification in the risk assessment.

The risk assessment is, of course, specific to the particular product with digital elements. However, I think we have to agree that in most foreseeable cases vulnerabilities can arise. These include the discovery of latent vulnerabilities that were present when the product was shipped (or last updated) that have since been discovered, and the potential for a vulnerability to be activated, created or added by connection to the device.

The internet or network connection is important here. Without it you might rely more on the physical inaccessibility of the firmware. It’s also key to the ability to provision updates (other than by physical means).

Remember that any product capable of connection to a network or device is in scope. However, if there is no actual internet connection – directly or indirectly via a local network - and access to any external ports is physically restricted, there could be a case to assert that updating is “incompatible with the nature” of the product. If the product can’t be updated, and is not connected, it’s obviously much more challenging for an attacker to access the firmware. Of course, physical tampering might be possible, and that’s something for the risk assessment to also consider.

The conclusion here is that for a connected device, the ability to provide updates is inescapable, and the firmware should therefore be protected (at least) by authentication. For non-connected devices secure boot is best practice, but the answer to whether it is mandatory must be case-specific. Can you come up with another way to ensure the integrity of the firmware?

No Harmonized Standard for CRA (yet)

In the absence of a corresponding harmonized standard, other standards become important. This is because demonstrating conformance to a similar recognized standard is accepted practice in this situation, and also because it’s not unlikely that guidance will be issued which explicitly mentions other standards, thereby giving them a legal standing. EN 303 645 – perhaps the closest European standard to CRA in terms of intent, although targeted at consumer devices – already states, quite simply: “The consumer IoT device should verify its software using secure boot mechanisms.” You might think that the argument ends right there. However the use of “should” rather than “shall” means that even this standard leaves the door slightly ajar. So we come full circle to the CRA’s “shall protect the integrity of stored…programs” as perhaps the strongest evidence for the need for secure boot in most situations.

Why So Negative?

This article, like most of my discussions around embedded cybersecurity, revolve around whether this or that requirement can be rightfully avoided. In one sense this is understandable given that time and effort is required for implementation.

However, the customer mindset is changing, and we’re moving towards a world where customers actively prefer secure products. Remember that the risk assessment as discussed here has to be published in the product end-user documentation. So my final thought is that surely we want to deomstrate that we are providing a secure product, not tying ourselves in knots - in public - just to avoid implementing the most basic form of security?

** Please subscribe for more CRA-centric news and analysis! **