Column: System security
Code RED for cybersecurity The European Commission’s Radio Equipment Directive 2014/53/EU (RED) provides a regulatory framework for radio equipment, setting essential requirements for safety and health, electromagnetic compatibility (EMC) and radio spectrum efficiency. Article 3.3 of the directive includes device requirements related to specific categories of radio equipment, ranging from common interfaces to cybersecurity. RED compliance is required for any new products entering the market from August 2024. RED mandates that network-
connected devices “should not be easily compromised”, which means that the device’s security features must prevent third parties from running code on IoT devices at scale. One of the objectives of preventing unauthorised boot code or software from running on devices is to protect the network from cyberattacks originating via IoT devices.
How secure boot works Verifying the authenticity and integrity of the firmware and software components on a device at boot time is typically carried out by an embedded trusted Root of Trust (RoT), such as a hardware-based security module (i.e., secure element, Trusted Platform Module) or a trusted execution environment (TEE). The digital signature used in
secure boot is based on public key cryptography, where the bootloader and other critical software components
RED compliance is required for any new product entering the market from August 2024.
RED mandates that network-connected devices “should not be easily compromised”
are digitally signed using a private key known only to the original device manufacturer. This private key (ODM Kpriv) is used to sign a public key (ODM Kpub), and the resulting digital signature (ODM Certificate) is typically stored and protected in the hardware RoT. When the firmware checks the digital
signature of the bootloader and other software components, it uses this public key via secure API commands to the RoT crypto service. If the RoT detects that the signature is not valid, or detects that the integrity of any component has been compromised, the software will not load and the device will not boot. It is essential to implement additional
security features that verify the runtime environment integrity. Runtime protection profiles the firmware and initiates verification checks across several attack vectors to prevent memory manipulation attempts. The secure boot process is also
triggered when device software updates are available. It detects and verifies the authenticity and integrity of the software update prior to switching from the previous software version to the updated software component. Downgrading the device software to earlier versions is typically blocked, unless properly authorised. This feature is referred to as an anti-rollback mechanism.
Required security Secure boot and secure loading processes are required to ensure that devices function as the ODM intended. Devices without a secure boot feature can’t detect or prevent third parties from executing unauthorised boot code on the device. EU legislation mandates that devices should not be easily compromised and secure boot is essential to meet these legislative requirements. The new cybersecurity regulation will
provide market surveillance authorities with a means of forcing product manufacturers to withdraw products from the market. As organisations transform into service-led business models that allow them to be successful in the digital economy, security has an increasingly important role in delivering and using secure services.
www.electronicsworld.com May 2023 13
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
