High security, minimal design disruption: how to choose the right hardware for compliance with new IoT cybersecurity regulations
By Nicolas Guilbaud
EMEA Business Development Manager (Cybersecurity), Future Electronics
Read this to find out about:
- New regulations governing cybersecurity, including additions to the Radio Equipment Directive, and the new Cybersecurity Resilience Act
- The company-wide implications of programs to ensure compliance with the regulations
- The three hardware options for implementing a security capability sufficient for compliance
OEMs everywhere must deal with a wave of new cybersecurity legislation, including the UK Product and Security Telecommunications Infrastructure (PSTI) law coming into effect in 2024, and the European Union CE RED (Radio Equipment Directive) 2014/53/EU certification for wireless devices, coming into force in August 2025. Implementing security protection features in new embedded product designs is now a task that no OEM can postpone.
The first response of many design engineers will be to evaluate competing hardware products that implement cybersecurity functions. In fact, compliance with cybersecurity regulation calls not only for specific hardware capabilities, but for processes and systems implemented across the product lifecycle from design through deployment to end of life.
The OEM’s evaluation of a security component therefore needs to be made in a wider context than just the features and specifications of the device itself. Wider factors to be taken into account include:
- The value of protecting investment in legacy product IP
- The flexibility and security know-how in the OEM production facilities
- The vulnerability of the product/system to cyber attack, and the strength of security protection it requires
The coming wave of cybersecurity regulation
OEMs based in Europe have a special reason to turn their attention to cybersecurity now: the clock is ticking on the introduction of two hugely significant new pieces of legislation enacted by the European Commission, with many more coming in other parts of the world. First in Europe come changes to the articles of the CE RED regulation.
- New article 3.3(d) improves network protection. Device manufacturers will have to include features that avoid harming communication networks and prevent the device from disrupting the functionality of websites or services.
- New article 3.3(e) strengthens personal data and privacy protection. For example, device manufacturers will have to implement measures to prevent unauthorized access or transmission of consumers’ personal data, shown in Figure 1.
- New article 3.3(f) reduces the risk of fraud. Device manufacturers will have to include features such as better user authentication to minimize exposure to the risk of fraudulent electronic payments and monetary transfers.
The new regulation covers radio devices that can communicate over the internet, whether directly or via other equipment.
Fig. 1: The EC cited studies highlighting the risk from toys that spy on the actions or conversations of children when explaining the introduction of CE RED [1].
The regulation states the obligations imposed on OEMs. But how is an OEM to demonstrate that it complies? Full details of the compliance regime are still to be defined, but product developers can work on the basis of EN 18031, a harmonized standard governing cybersecurity. This new standard is still in draft form; the existing ETSI 303 645 and IEC 62443-4-2 standards can be used to guide the early stages of cybersecure product development until EN 18031 is ratified.
It is already known, however, that the standard will require new subsystems and capabilities in electronics systems to provide for:
- Secure boot and secure firmware update
- Secure storage of vulnerable or critical data, such as private keys
- A secure access control mechanism to authenticate connections
After CE RED, the second piece of EU legislation is the Cyber Resilience Act (CRA), which will extend the scope of cybersecurity regulation to internet-connected wired devices in 2026 or 2027, and which will add more technical and process requirements on all connected devices, including mandatory tracking of exposure to known threats for a period of up to five years.
Elsewhere, vertical sectors such as medical devices have their own sets of regulatory security requirements in Europe. And globally, governments in North America and Asia are taking cyber threats equally seriously, and enacting new requirements in regulations or guidelines.
Company-wide implications
The provisions in regulations such as the UK PSTI, and the EU CE RED and CRA, mean that cybersecurity compliance has to be about more than just secure hardware design. For instance, the requirement to support secure firmware updates means that an OEM must institute various capabilities:
- Monitoring of common vulnerabilities and exposures (CVE) notices. A hardware and software bill-of-materials maintained for every production unit is required to know which devices in the field, if any, are affected, and need a security patch delivered as a local or an over-the-air (OTA) update.
- A secure update development and delivery system
Similarly, the requirement for storage of security-critical data such as private keys calls not only for a secure repository, protected behind physical and logical barriers, but also a set of processes that are applied across the company, and a culture that reinforces the commitment of staff to following security procedures.
So secure hardware is not sufficient to ensure compliance with the new wave of cybersecurity regulations, but it is necessary. So which factors will affect the component choices that most manufacturers of IoT and other connected devices will make?
Freedom to preserve existing design IP
If the remarks above suggest that cybersecurity compliance involves root-and-branch reinvention of company processes, at least the secure hardware component can entail far less disruption: there is a way to add cybersecurity capability to existing product designs, while preserving the existing product architecture, keeping the same microcontroller or microprocessor, and maintaining IP such as firmware and application software.
This can be achieved by bolting on one of the latest generation of secure elements (SEs) to existing or new designs. Widely available from manufacturers including Infineon, Microchip, NXP Semiconductors and STMicroelectronics, SEs provide a full range of security capabilities compatible with the requirements of CE RED, the CRA and other cybersecurity regulations, shown in Figures 2 to 4. A typical secure element will provide features such as:
- Secure channel establishment with a remote host
- A signature verification service, required for secure boot and OTA updating
- Cryptographic functions
- Key pair generation using certified random number generators
- Secure system architecture offering protection against logical and physical attack
The appeal of the SE as a solution to the problem of regulatory compliance is that it can easily be bolted on to systems based on any kind of controller or processor, even down to small 8-bit microcontrollers. SE manufacturers ease the integration process by providing ready-made drivers and middleware for host controllers, and many support the SE products with security certifications.
In some circumstances, SE manufacturers also provide secure provisioning services for the products: this means that they maintain secure production facilities in which each device can have its unique ID and secure keys programmed into it before shipment to the customer. Future Electronics also offers a secure provisioning service to distribution customers.
Bill-of-materials cost for upgrading cybersecurity protection with an SE is moderate: a good quality SE can be purchased for less than an entry-level MCU. It is, however, important to recognize the limitations of these low-cost devices: secure elements are optimized for storage of secrets only, and provide sufficient bandwidth to transmit these secrets. This means, however, that most SEs do not provide high data storage capacity, and typically only a relatively slow I2C or serial peripheral interface to the host.
But for mainstream microcontroller applications that require security functions such as authentication, secure boot, and strong resistance to logical and physical attack, an SE will normally be suitable, and involves the least possible modification of existing design IP.
Fig. 2: The EdgeLock® SE050 from NXP Semiconductors, a popular secure element for use in embedded designs
Fig. 3: The ATECC608B TRUST board, an add-on board for working with the ATECC608B, a secure element from Microchip
Fig. 4: The Infineon OPTIGA™ Authenticate S, a turnkey hardware-based security solution for enhanced device authentication to protect against counterfeiting
Streamlined system design
Some applications, however, are based on a high-end microcontroller or microprocessor with a high-performance core such as an Arm® Cortex®-M7 or Cortex-M33, or Cortex-A series. These products generally have a rich set of security features built-in, including cryptographic acceleration, random number generation, and secure partitioning in the form of Arm TrustZone® technology, shown in Figure 5. This gives the OEM the possibility of achieving compliance with regulations such as CE RED and the EU CRA without the addition of an external SE.
This will almost certainly be the right option for applications that involve high-speed secure data transfers at rates faster than the SPI or I2C interface of an SE can handle.
Fig. 5: Block diagram of the STM32MP135F MPU from STMicroelectronics, showing the security capabilities built into the chip, including protection against physical tampering
But for others, the drawbacks of integrated security functionality can outweigh the benefits. First, most high-end MCUs and MPUs lack strong protection against physical attack: this protection is available in an SE. Second, developing a system to run on TrustZone technology is hard: developers need to learn the OP-TEE and TFM software frameworks, and integrate them with the application, and this can often result in extending development time and delaying time-to-market. In addition, TrustZone applications make heavy use of memory resources, this is particularly a problem for MCUs, which have limited on-board RAM and Flash memory.
In practice, then, many applications based on a high-end MCU or MPU use an SE for some or all of the system security functionality, for instance, implementing secure boot in the processor and choosing to have network authentication managed by a secure element. As well as simplifying the development process, this also enables the OEM to take advantage of the broad availability of secure provisioning services for SEs, services for provisioning an MCU or MPU are scarcer and more expensive.
For extreme cybersecurity protection
There is one other broad category of hardware option for compliance with cybersecurity regulation: FPGAs.
An FPGA provides a flexible approach, enabling the OEM to specify exactly the security functions that are needed, and to update the design in response to changes in the external threat environment without requiring a hardware re-spin. This flexibility extends to enabling ultra-high performance security: an FPGA is today the only way to future-proof a design against the risk that quantum computing makes existing asymmetric cryptographic security algorithms obsolete.
Of course, an FPGA is a specialist component that requires knowledge of the VHDL or Verilog design environment provided by the FPGA manufacturer. But when the very strongest security protection is required, an FPGA is normally the right choice of hardware.
Getting the architecture decision right
This article provides high-level guidance on the issues to consider when modifying a design or creating a new design for compliance with security standards. Any embedded design can be made compliant, and the wide choice of SEs on the market allows OEMs to achieve the right balance of cost, performance, and protection.
The hardware should not, however, be the starting point of the ‘design for security’ process. In fact, not even compliance should be the starting point.
Instead, the right place to start is an assessment of the needs of the application: how big a security threat does it face, and might this threat grow stronger over time? What is the lifetime of the product in the field? How important is it to maintain existing design IP, and a familiar hardware architecture?
By considering these high-level questions, OEMs can ensure that compliance is achieved and the right level of security protection without the risk of over-engineering the solution. An ideal security design minimizes bill-of-materials cost and development time while allowing the OEM to hit the target for launch to market.
For advice on these architectural considerations, and the appropriate design strategies, cybersecurity experts at Future Electronics can bring advice based on experience across thousands of customer design projects.
Reference