Sense of security

Nick Flaherty uncovers new ways to make e-mobility software safer

A competition in Japan has discovered 49 vulnerabilities in automotive software, of which the developers were unaware.

In the Pwn2Own Automotive 2025, researchers targeted EV-charging electronic control units (ECUs), where a flaw allowed the manipulation of charging parameters in the powertrain ECU, risking battery thermal runaway. As this had not been noticed before, it is called a ‘zero day’ vulnerability.

Another team achieved full vehicle control by compromising the central gateway ECU, which routes communications between critical systems. Other approaches included shellshock attacks, during which harmful commands could be triggered remotely, and unknown app execution, which could lead to data breaches, unauthorised access and degraded system performance.

Risks exist across the e-mobility ecosystem. For example, a breach in 2024 of a car maker’s customer portal exposed not only user data, but also indirect access to telematics ECUs in connected vehicles.

Attackers exploited weak authentication of the application programming interface (API) to send unauthorised commands to a vehicle head unit, potentially altering ECU configurations (for example, disabling alarms or geofencing).

This incident underscored the risks of insufficiently secured backend systems interfacing with in-vehicle ECUs, prompting the company to isolate critical ECU communication channels from customer-facing APIs.

Similarly, weak encryption of a firmware delivery of an update showed malicious actors could intercept and modify ECU update packages, injecting code to disable collision-avoidance systems.

All this highlights the ongoing challenges when developing secure systems for e-mobility. If a system is not secure it cannot be considered safe.

Standard bearers

Developers are now learning from the first implementations of security systems to refine and improve their designs.

Modern vehicles come with more than 100 electronic control units (ECUs), which run millions of lines of code written in the C programming language.

For software-defined vehicles, the number will be even higher as the computational power required to run them scales up, creating a huge attack surface for vulnerabilities.

The database of Common Vulnerabilities and Exposures (CVE) includes an automotive product security platform allowing unauthorised access to the host system that could lead to remote code execution (CVE-2023-42419); a vulnerability in the Tesla Model 3 web interface that allows a denial-of-service attack, which prevented the user from seeing the speedometer, or using the turn signal, climate control or navigation features (CVE-2022-10558).

Also, a high severity relay attack vulnerability (CVE-2022-38766) in a popular EV in Europe, which allowed unauthorised access to vehicles and the ability to remotely start them. 

Legislation around the world over the last decade has required car makers to provide more secure systems in both hardware and software to protect vehicles from attack. This is being achieved at the hardware level with root-of-trust and encryption techniques, and in software though tools to identify vulnerabilities and reduce the attack surface – the number of places where a potential vulnerability might let an attacker in.

The Advanced Encryption Standard (AES) technologies used today with 128 bit and 256 bit keys are safe from cracking by today’s supercomputers, but are vulnerable to the coming generation of quantum computer systems. This has led to the development of post-quantum cryptography (PQC) algorithms that need to be included in vehicle security infrastructure.

Developers have had cyber requirements in place for vehicles for several years. They have been through one development cycle with the first platforms and are now having to apply the learning from this to all their vehicle platforms.

This is marking a shift from developers looking at how to implement security to ensuring a secure system through penetration testing and developing processes to close the gaps found in the first security audits. Cybersecurity now includes ongoing monitoring, and current implementations need to respond to attacks that emerge over time.

Cryptographic measures are being introduced more widely as a top-down requirement from OEMs who are asking suppliers to deliver secure systems. These systems have authenticated network communications and secure software updates, as well as verification of software on the ECU when the system boots up.

The challenge is how to move across platforms, from a low-end ECU to a high-end controller. Encryption is the golden solution, but it doesn’t prevent vulnerabilities in other areas, such as the controller area network (CAN) injection in headlights, so cybersecurity includes not forgetting the basics.

The car maker found this out after a researcher got involved after a series of thefts. The thieves disconnected part of the headlamp and used a malicious device to send signals to the control CAN bus within a vehicle, allowing the doors to open and the car to start without the key or remote control.

The thieves needed to purchase a relatively expensive emergency start device, costing around £2500 to £4000, and gain physical access to the vehicle’s CAN bus communication wires for an uninterrupted period of time.

Once connected, the device can send a prioritised series of CAN signals to bypass the vehicle’s security and immobiliser systems, which could unlock the doors and turn on the ignition. The thief can then disconnect the device, enter the vehicle and start the car without the key.

Enhanced security hardware was added to the latest versions of the models previously targeted, and the platform was changed to avoid the fault injection attack. However, the vulnerability still exists.

In late 2024, thieves exploited vulnerabilities in adaptive headlight-control ECUs, which were improperly isolated from the vehicle’s CAN bus. By physically accessing the headlight wiring, attackers sent spoofed CAN messages to the powertrain ECU, bypassing immobilisers and enabling keyless theft.

This attack emphasised the importance of segmenting non-critical ECUs such as lighting systems from safety-critical networks and implementing CAN bus intrusion-detection systems (IDS).

One key standard for building secure automotive systems is AutoSAR. This standard has detailed guidelines for cybersecure development (see below) and there are various software tools with techniques such as static code analysis that can help developers avoid the pitfalls.

AutoSAR is also changing the way security is implemented, with strategies moving away from securing the perimeter of a system with a hardened exterior to a zero-trust environment that secures everything inside to avoid any threats that appear in the network.

It is based on a physically unclonable function (PUF), which uses part of a chip with a unique feature, such as SRAM memory. This provides a unique digital fingerprint for a device that can be used as the basis of the security, or a root of trust.

This also requires memory-safe code, recognising there could be hundreds of holes in the attack surface from vulnerabilities such as de-allocated memory and buffer overflows.

This need for memory-safe code is leading to the use of new languages such as Rust, which avoid these problems, and tools to analyse existing C code for such vulnerabilities. There are now projects to use AI to convert C libraries to Rust, and with this comes guidelines for its safe use.

The basic MicroSAR software, based on AutoSAR, includes security modules that can be tailored by developers.

Building a secure architecture in a vehicle requires key storage and complex cryptographic calculations in the ECUs. For this, semiconductor manufacturers integrate hardware security modules (HSM) into microcontrollers.

These hardware trust anchors (HTA) serve as a trustworthy source of cryptographic calculations. In addition, moving such calculations to the HSM reduces the load on the microcontroller and frees up resources for the application.

MicroSAR firmware works with the HSM in chips from various semiconductor manufacturers.

The software can be adapted to provide the following: functions for saving keys; secure boot, symmetrical and asymmetrical cryptographic algorithms; and basic functions with the use of hardware accelerators in the chips. This can also support the updating of encryption keys.

Crypto drivers support various types of hardware trust anchors, such as the Secure Hardware Extensions (SHE) and the HSM, and it acts as the interface between the MICROSAR stack and HSM firmware.

This also includes the interfaces for Cryptographic Algorithms (CRYIF), Secure Onboard Communication (SecOC) and the Transport Layer Security (TLS) client for secure communications over Ethernet.

Secure memory

By separating the memory from the host and HSM, content worth protecting remains encapsulated in the HSM and separate from the rest of the application. Cryptographic key material is introduced during production and only referenced during runtime calculations, so the keys never have to leave the HSM. This prevents keys from being read by hacker attacks. 

With large enough memory, a MicroSAR HSM can store a flexible number of keys, certificates or other content, with the amount limited purely by the hardware resources.

To prevent compromised software from starting, more ECUs are checking the authenticity of the ECU application at startup time. The HSM firmware performs this task securely and efficiently to reduce the required startup time. It is even possible to perform this check concurrently with the system startup. 

The HSM handles the calculation of the message authentication code (MAC) for secured messages and this allows the recipient to check its authenticity. Calculating and verifying this code generates additional effort and increases the load on the host CPU. The HSM supports this calculation by hardware-accelerated calculation of the MACs. 

The Transport Layer Security (TLS) protocol widely used on the internet is used to secure external communications. The HSM relieves the main processor of the time-consuming TLS connection setup and ensures content that requires protection, such as private keys, is separated from the rest of the system.

In addition, the HSM can encrypt and decrypt the user data in a hardware-accelerated manner. 

Rust language

Automotive software is traditionally developed in C and C++ as these languages are most suitable for resource-constrained embedded systems, but they are highly prone to issues related to memory safety and data race conditions.

An up and coming alternative is Rust. This is a programming language designed to overcome these limitations without the overhead of a runtime garbage-collection mechanism. In tests, the efficiency of Rust in terms of execution time and memory usage is comparable with C and C++.

The built-in safety from memory leaks and race conditions offered by Rust makes it suitable for automotive software where functional safety and security are highly valued. Considering this, organisations such as AUTOSAR and SAE have formed groups to evaluate the usability of Rust in automotive middleware and system software. 

More modern software development tools include dependency management through crates, linter checks, formatting and documentation, among other things. The Rust compiler produces accurate warnings and errors, which help developers to fix issues quickly.

Rust enforces memory safety at compile time. The Ownership Based Resource Management (OBRM) approach used by Rust for handling data ensures memory safety without compromising runtime efficiency. This approach ensures safe sharing of data among multiple execution threads without race conditions.

The language also provides good mechanisms for interoperability with C and C++.

The foreign function interface (FFI) provides built-in support for binding with external C code. While C++ bindings are not directly supported by FFI, a library called Cxx provides a safe mechanism for calling C++ code from Rust, and Rust code from C++.

This makes it possible to implement new features in Rust in a project where the primary language of development is C or C++, or use existing C or C++ libraries in a Rust application.

Rust inherently offers memory safety, thread safety and type safety, which is a prerequisite for developing functionally safe and secure software. 

A new generation of automotive development tools for Rust are now ISO 26262-compliant for vehicle developments.

The Ferrocene Language Specification (FLS) is a qualified Rust tool chain for safety-critical systems for automotive, avionics, space and railway.

AutoSAR has also formed a subgroup within the Working Group for Functional Safety (WG-SAF) to investigate how Rust could be applied in the adaptive platform context.

With the interoperability features available in Rust for C and C++, it is possible to develop some components of the project in Rust and then integrate these components with the rest of the C++ code. Cxx provides a safe mechanism for two-way binding between C++ code and Rust code.  

Although it is technically feasible to combine Rust and C++ components, it nevertheless poses certain challenges for maintenance and project management. The software architecture can become complex, and the development team will inevitably require both C++ and Rust developers. If existing C++ developers plan to learn and develop in Rust, this can have a significant learning curve.

Rust matches C++ in terms of performance, and in some quarters much more, particularly when it comes to memory safety, and managing runtime issues and security vulnerabilities.

Developers are increasingly confident about using it in the automotive space, and as automotive software evolves for software-defined vehicles, moving to Rust is expected to become more attractive as it could also help manage the cost of maintaining the software after the launch of the vehicle, and allow product teams to focus on new features.

However, there are millions of lines of C and C++ code widely used by developers, and it is a significant challenge to port this code to Rust. There are now projects to use AI tools to convert C libraries to Rust to ease this challenge, with guidelines to help.

MISRA AC

These issues have also been addressed by the MISRA consortium, which, since the 1990s, has provided best practice guidelines for the safe and secure application of both embedded control systems and standalone software.

The collaboration between manufacturers, component suppliers, engineering consultancies and academics started as a project for the UK government’s SafeIT research programme, and it developed guidelines for the creation of embedded software in road vehicle electronic systems.

In November 1994, development guidelines for vehicle-based software were published for functional safety using a restricted subset of C, a decade before work began on ISO 26262 at the international level.

This has been extended to automatically generated C code from development tools. This auto-generation can reduce the risk of error and improve the overall quality of the code.

The MISRA AC documents deal with the application of its guidelines to automatically-generated Code (AC). Using these guidelines improves portability through the avoidance of compiler- or platform-specific constructs and it avoids unexpected application behaviour.

 It can identify unreachable or unfeasible code, which often suggests a defect and a potential security vulnerability, and it can reduce unsafe and insecure coding practices by prohibiting certain language constructs. This reduces program complexity and helps to improve program testability to ease compliance with functional safety and security standards.

Real-time OS

Real-time operating systems (RTOS) can also help provide more secure operation in an ECU. This software can be written with minimal code to reduce the attack surface, so it can be more easily certified to ISO26262 ASIL D for safety and ISO23414 for security, which can provide memory protection, fast boot and fast execution with a simple API for developers.

This can allow applications, middleware and drivers to run outside of kernel memory space, but still be secure. The memory can be partitioned into several distinct regions, which guarantees the safe and secure isolation of tasks assigned to them.

CHERI projects

The demands of developing secure systems is also leading to new types of hardware, not just secure blocks in chips.

The Capability Hardware Enhanced RISC Instructions (CHERI) project has developed a chip architecture that avoids the memory problems and risks, and this has been used in both ARM and RISC-V processor design. An automotive project called AutoCHERI has been testing this out with penetration testing.

However, this will take time to be implemented and qualified in automotive chips, even with IP for processors available.

CHERI has been in development since 2010, and it is now being tested in a number of ways for automotive uses, analysis and threat modelling. Specific use cases include vehicle diagnostics data, and processing data from CAN through the telematic control unit (TCU) and up to the cloud.

It can also be used for over-the-air (OTA) software updates of the TCU, pulling software packages from the cloud and cryptographically verifying them, as well as communicating with roadside infrastructure via cellular-V2X protocols.

It is a new CPU instruction-set architecture offering two new features: it enforces the memory safety of pointers and introduces compartmentalisation.

The CHERI memory protection feature allows historically memory unsafe programming languages such as C and C++ to be adapted to provide strong, compatible and efficient protection against many widely exploited vulnerabilities.

The scalable compartmentalisation feature enables the fine-grained decomposition of operating system (OS) and application code to limit the effects of security vulnerabilities.

RISC-V

The first automotive core to implement CHERI fine-grained memory protection provides 100% coverage in checking for memory errors. It uses the RISC-V open instruction-set architecture (ISA) and includes logic in the core check read/write permissions, and it validates memory accesses.

The core has ISO/SAE 21434 and ISO 26262 compliance up to the ASIL D integrity level, and the CHERI capabilities are implemented with a small increase in area and low impact on performance to protect against known and future vulnerabilities, and to help simplify the development of secure systems.

However, this requires recompiling the code with a CHERI-aware compiler, which can be a complex and time consuming task to meeting automotive certification. Instead, there is the ability to recompile only critical areas of code to reduce software efforts to gain the protection of the CHERI architecture.

The baseline microarchitecture is a 64 bit, dual-issue core, which has been extended to efficiently handle capabilities and implement CHERI’s new instructions and functions. The register file has been extended to 129 bits to accommodate, while the memory system has been extended to atomically handle capability tags while still using standard interfaces. 

Most CHERI operations are implemented in a custom unit in the core with all safety checks, so every instruction is issued to the custom unit, along with another execution unit, such as the Load/Store Unit for a store, and their outputs are combined when the instruction is committed. 

The core incorporates optional safety mechanisms and advanced security features, providing system engineers with flexibility with a fully verified and supported core IP, which adds the RISC-V Scalar Crypto Extension.

Validating and testing

Validating automotive cybersecurity requires connectivity gateways, a test management server, a reconnaissance and fuzzing server, and a library of known vulnerabilities and threats.

Car makers must perform controlled cyber attacks, functional cybersecurity tests, protocol fuzzing and vulnerability scans to validate that their implementations meet their cybersecurity goals.

Testing must cover multiple attack vectors and account for all communication interfaces, including cellular, wi-fi, Bluetooth, CAN bus and Automotive Ethernet.

To manage cybersecurity risks in vehicle components and subsystems, OEMs must evaluate component and subsystem vulnerabilities against known vulnerabilities and emerging cyber threats.

If vulnerabilities are found and remediated, re-verification tests are required to ensure the remediations didn’t introduce new vulnerabilities.

A test execution environment helps to automate verification testing, improve test coverage and demonstrate compliance within a cybersecurity management system (CSMS), as outlined by the ISO/SAE 21434 standard and mandated by regulations such as UN R155.

This allows automotive cyber-security testing from the hardware level through all layers of the OSI stack. This allows developers to find and fix vulnerabilities with hardware, software and services into a single test system.

Devices under test are connected to onboard interfaces and the software emulates attacks against vehicular interfaces to validate automotive cybersecurity against a database of known threats.

Post-quantum algorithms

The US National Institute of Standards and Technology (NIST) has officially approved a new set of encryption algorithms for PQC.

The result of an eight-year competition, these algorithms are used in new standards from NIST that replace current encryption methods.

In the US, the NSA has already mandated that national security systems adopt PQC by 2030, while the UK’s Cyber Security Council strongly recommends implementing them.

By ratifying and publishing its PQC standards, NIST is triggering a significant cybersecurity transition. Three algorithms are ready to publish with key encapsulation, technology that protects the keys and a signature to verify firmware when software has been downloaded.

Digital signatures are used to prevent malware attacks, particularly for protecting downloads and updates from being intercepted and compromised.

There are digital signatures and key encapsulation that lead to various use cases, and chip makers are using these in automotive chips.

The deployment includes a root-of-trust that already includes PQC, so even if the requirements for security change, these can still update in a post-quantum, secure way. That’s the digital signature part.

Key encapsulation is more suited to protecting session keys and data from interception, but this requires agreement with developers across the whole vehicle, from the wireless gateway to the telematics unit and to the ECUs.

The PQC algorithms specified by NIST are ML-KEM (formerly Kyber), ML-DSA (Dilithium) and SLH-DSA (SPHINCS+).

Future

The hardware and software development tools for building secure e-mobility platforms now provide a proven ecosystem that protects systems and meets regulatory requirements. This first generation of development is now evolving across the whole range of ECUs.

However, there are still considerable challenges to securing e-mobility systems, from new protection algorithms to developing reliable, safe code and the available hardware that is secure by design. The threats are ever-evolving, with hackers adopting new techniques in different places, as shown by the CAN injection attacks through the headlight systems.

One increasingly important area is threat intelligence. This requires sifting through vast quantities of intelligence and narrowing down the threats to something actionable to feed into development programs. This is one of the most common requests from developers and an area where AI can assist.

Acknowledgements

With thanks to Paul Wooderson at MIRA Horiba and Chris Smith at Green Hills Software and Ricardo Camacho at Parasoft for their assistance with this article.

Some suppliers of cybersecurity solutions