Adding cybersecurity to a car alongside existing protection against technical failures may disrupt critical reaction times for preventing an accident. Engineers can balance this through combined risk analysis, writes Diego de Azcuénaga.
The technical tension between functional security and cybersecurity demands measures to balance the latency introduced by cryptographic features (such as secure hardware extensions and authenticated boot) with the strict real-time fault detection intervals needed to maintain ASIL ratings.
For this purpose, co-engineering methodologies are used, such as combining HARA (Hazard Analysis and Risk Assessment) and TARA (Threat Analysis and Risk Assessment) into a unified workflow.
Among the use cases, modern ECUs implement HSMs that offload cryptographic primitives from the main processor, preventing real-time degradation in application tasks.
Time budget impact
The mathematical and operational conflict between real-time determinism and cryptographic computational overhead is manifested, for example, in the way data encryption impacts the time-triggered constraints of a braking or steering system.
The ISO 26262 standard defines the Fault Tolerant Time Interval (FTTI) as the maximum time that can elapse from the occurrence of a fault until the system executes a safe action (for example, deactivating the assistance or switching to backup mode).
In braking (brake-by-wire) or steering (steer-by-wire) systems, the dynamic control of the vehicle depends on closed, deterministic control loops, where the FTTI is usually extremely critical: between 10ms and 50ms, since any delay translates directly into metres of braking distance.
To guarantee message authenticity and prevent command injection attacks on the bus (such as the infamous remote CAN bus hack), the ISO/SAE 21434 standard requires security mechanisms such as AUTOSAR’s SecOC (Secure Onboard Communication). This adds an authentication label (CMAC) and a freshness counter to each data frame.
However, the message authentication required to mitigate risks identified in the TARA consumes critical clock cycles and precious microseconds on the communication bus due to the introduction of the SecOC delay.
Figure 1: Modern cockpits blend safety-critical driver displays with connected infotainment, demanding concurrent compliance with both ISO 26262 and ISO/SAE 21434 standards (source: Pexels)
Cryptographic latency vs real-time performance
In the case of a braking ECU, processing a CAN message requires following these steps:
- Receive the message
- Remove the CMAC label and the counter
- Locally calculate the cryptographic algorithm for example AES-128)
- Compare the result to verify that the command comes from the ADAS camera and not from an attacker.
The problem arises when this process takes, for example, 2ms per message due to software computation and the CAN bus is saturated, in which case the accumulated latency drastically reduces the FTTI margin. If the verification takes too long the braking system will react to outdated information, compromising the physical stability of the vehicle.
Thus, a poorly optimised cybersecurity system that causes a brake message to lose its FTTI becomes, by definition, a functional security failure under ISO 26262. This justifies why hardware and software can no longer be designed in separate silos.
Furthermore, engineers are forced to migrate to CAN FD (up to 64 bytes) or automotive Ethernet protocols because adding freshness passwords and cryptographic signatures to traditional automotive protocols (classic 8-byte CAN) destroys the available payload.
In this regard, new challenges are introduced in EDA tools to simulate jitter behaviour and ensure that the priorities of critical (time-triggered) messages are not displaced by lower priority encrypted traffic.
Unified risk analysis
The HARA methodology (ISO 26262) identifies physical vehicle hazards (for example, unintended acceleration) and assigns an integrity level (ASIL A to D) based on severity, exposure and controllability. These hazards always originate from random or systematic hardware/software failures.
Meanwhile, the TARA analysis (ISO/SAE 21434) identifies assets, threats, for example, message injection into the bus, attack vectors and attack feasibility to assign an impact rating (financial, operational, privacy, security).
Performing HARA and TARA independently duplicates efforts and creates contradictions in design requirements. For example, a cyberattack (TARA) that manipulates sensor data can simulate or cause a physical system failure (HARA). Therefore, the security impact of TARA should be directly derived from the ASIL classifications of HARA.
Figure 2: Illustration of multiple cyber threats that, if vulnerable or exploited, can lead to cyberattacks (source: MDPI)
Modelling tools
Graphical modelling tools allow for fault tree analysis integrated with attack graphs. This enables mapping the path from a software vulnerability (for example, a buffer overflow in the Bluetooth module) to the loss of control of a physical actuator in the chassis.
Engineers use model-based systems engineering with architectural modelling tools such as Ansys Medini Analyze, IBM Engineering Lifecycle Optimization, or Enterprise Architect.
The entire system is modelled, including sensors, microcontroller, actuators and data buses. The software then overlays both hardware failure modes (FMEA/FMEDA) and cryptographic attack surfaces onto this single model.
For example, if the model detects that a diagnostic interface has access to the power steering control bus, the tool automatically alerts that a TARA threat directly compromises a HARA ASIL-D security target.
Silicon-level mitigation
The industry can physically resolve the cryptographic latency conflict using the hardware architecture mapped into the design tools. It will focus on the chip’s internal architecture and the principle of domain isolation.
The need for hardware acceleration arises because software-based crypto processing of protocols such as SecOC is impractical for real-time architectures due to the jitter and latency it introduces to the CPU.
Specialised hardware, such as the principle of crypto offloading, reduces the load on the main execution cores of the automotive microcontroller. The application CPU problem arises when the main cores (such as ARM Cortex-R52 or Infineon TriCore) must be dedicated exclusively to executing steering or brake control loops in microseconds, ensuring compliance with ISO 26262.
This is where the HSM solution proves effective: an isolated subsystem within the same chip (a ‘chip within a chip’) with its own core (for example, a Cortex-M3 or a dedicated Risc-V engine), its own secure ROM/RAM and hardware cryptographic accelerators for AES, ECC and SHA.
Its benefit is demonstrated when, upon receiving an encrypted message via the CAN bus, the main CPU does not calculate the algorithm, but instead passes the packet to the HSM. The HSM then decrypts the message and verifies the hardware freshness counter in nanoseconds, returning a clean ‘true or false’ result to the main CPU. The application CPU thus retains its FTTI.
The HSM must be hardened to comply with both standards simultaneously and modern design tools implement internal hardware firewalls (resource protection units) that prevent malicious software or an attack on the application CPU from accessing the cryptographic keys stored in the HSM’s secure storage.
In practical terms, this ensures that, for example, even if the infotainment or connectivity firmware is hacked (ISO/SAE 21434), the attacker cannot inject code into the vehicle’s chassis control domain (ISO 26262).
Physical isolation in silicon allows designers to demonstrate to certification auditors that cybersecurity requirements do not interfere with critical ASIL-D safety functions.
Diego de Azcuénaga is a technical writer and electronics engineer
See: Automotive SBRFP devices feature avalanche energy ratings up to 145mJ
