Electric vehicle (EV) cybersecurity testing is performed throughout the vehicle development lifecycle. EVs can contain dozens of electronic control units (ECUs) and a battery management system (BMS), communicating over the controller area network (CAN) bus and automotive Ethernet. These interconnected systems can also create potential entry points for cyberattacks.
This article examines where security testing fits within the ISO/SAE 21434 development lifecycle. It also discusses how fuzzing can expose vulnerabilities on the CAN bus, and how fault-injection testing can be structured.
How do engineers prioritize cybersecurity risks under ISO/SAE 21434?
The ISO/SAE 21434 standard requires a structured risk assessment before any electronic system reaches production. Engineers call this process threat analysis and risk assessment (TARA). However, TARA does not test hardware directly. Instead, it’s a way to decide which threats justify fuzzing, fault injection, and penetration testing. Figure 1 lays out how that decision gets made inside the standard.
Figure 1. The threat analysis and risk assessment flow defined in ISO/SAE 21434, from asset identification to risk treatment decision. (Image: Sensors, MDPI)
The process starts with asset identification, followed by threat scenario identification. That step produces two outputs: attack path analysis and impact rating. The role of attack path analysis is to turn the threat scenarios into an attack feasibility rating. The impact rating, on the other hand, scores the damage scenarios.
Combining these paths determines the risk value, which ultimately informs the risk treatment decision. The risk score decides where testing effort goes next, whether that means fuzzing a single CAN message or running a full attack scenario matrix against the powertrain.
Why is the CAN bus vulnerable to fuzzing attacks?
Fuzzing sends randomized data into a system to see how it responds. On the CAN bus, that means keeping a legitimate arbitration ID while randomizing the bytes in the data field. Some ECUs check whether a CAN message has the right ID, but not whether the data inside it makes sense.
An ECU like that treats a fuzzed frame as a normal command and acts on it. An example of such a fuzzification process is shown in Table 1.
Table 1. CAN identifiers, randomized data payloads, and the associated vehicle functions used in a black box fuzzing test set. (Image: Applied Sciences, MDPI)
Out of the six fuzzing test cases, two targeted the left turn signal, each with a different byte pattern. The wiper, the high beams, the seat belt warning light, and the sunroof each took one fuzzed frame. Every one of these five functions responded to a corrupted frame carrying a valid arbitration ID. That is the core weakness fuzzing exposes.
The CAN bus uses identifiers for message arbitration and prioritization, but provides no inherent authentication of the sender or message content.
What does a complete matrix for fault injection testing look like?
Fuzzing one CAN message, as shown above, demonstrates the vulnerability. It does not, by itself, cover every attack an EV needs to withstand. So, coming up with a full matrix of possible attacks is necessary to offer maximum protection for EV cybersecurity. Assigning each possible attack type to a target, timing, and trigger condition is a much more organized way for this purpose.
Such an approach is shown in Table 2, where nine attack scenarios are cataloged for a vehicle in the loop test setup.
Table 2. Nine attack scenarios with their target CAN signal, injection interval, and trigger condition, used to validate a vehicle in the loop cybersecurity testbed. (Image: IEEE Access)
The scenarios cover sniffing, injection, spoofing, denial of service (DoS), tampering, and fuzzing, with each targeting a specific signal and timing window. One injection attack manipulates the steering angle values every 10 ms, while a tampering scenario falsifies the brake activation signal every 20 ms. A DoS attack floods the same steering angle sensor message every 1 ms to overwrite legitimate readings.
Here, an important aspect to note is that timing matters as much as the target. The spoofing scenario against the engine speed message injects every 100 ms, while the DoS and fuzzing attacks flood the targets every 1 ms. This hundredfold difference shows how often a corrupted value shows up.
Summary
When working on EV security, especially in cybersecurity, relying solely on component-level testing is insufficient. Start by conducting a TARA to independently evaluate threat feasibility and impact ratings. Know that the CAN bus remains vulnerable to fuzzing and requires continuous monitoring. Finally, mapping many possible attacks into a clean matrix ensures we do not miss any. The variety of injection intervals in the fault injection matrix highlights the complexity challenges of scaling the system.
References
- Recommendation for Cyber Security Interface Agreement (CSIA), with reference to ISO/SAE 21434, German Association of the Automotive Industry
- ICVTest: A Practical Black-Box Penetration Testing Framework for Evaluating Cybersecurity of Intelligent Connected Vehicles, Applied Sciences, MDPI
- A Vehicle-in-the-Loop Simulation-Based Framework for Automotive Cybersecurity Evaluation, IEEE Access
- Cybersecurity Testing for Automotive Domain: A Survey, Sensors, MDPI
EEWorld Online related content
- What you should know about cybersecurity and EV charging infrastructure
- How to protect EVs from malicious hackers and cybercriminals
- Navigating in-vehicle network communications securely
- Cybersecurity testing in 5G automotive designs
- Safety and cybersecurity for the connected car
- Exploring the CANbus with an oscilloscope
Filed Under: FAQs, Featured Contributions