Flexibility vs. Security vs. Resources Trusted Execution Environments in Automotive Real-Time Systems

Real-time environments have always been subject to high demands for efficient and resource-saving implementation, but in the Software Defined Vehicle, additional requirements arise. Trusted Execution Environments (TEEs) could offer a solution here.

"Electronic control units and software of increasing complexity have become essential to the operation of road vehicles in recent years. This software is often updated to increase functionality and maintain the safety and cybersecurity of road vehicles" [1]. When even an ISO standard states this in its introductory chapter, it must be significant. Whether it’s new legal regulations on data protection (e.g., GDPR) or software updates (e.g., ISO 24089:2023-02), functional requirements regarding online connectivity or customer experience, or even technological challenges, such as the anticipated advent of quantum computers in the foreseeable future, these and other mandates result in specific technical tasks, such as securing confidential data, encrypting communication channels, or ensuring the updateability of security-relevant program components. Trusted Execution Environments can offer solutions to some of these problems. By isolating particularly sensitive data and program components, they provide protection against manipulation and unauthorized access, thereby making a significant contribution to achieving the security goals of confidentiality and integrity.

But a vehicle control unit must not only meet these seemingly new challenges. There are additional requirement areas that strongly influence the selection of hardware components, particularly microcontrollers. These include, above all, safety, which makes real-time capability essential for many significant vehicle functions. Furthermore, cost pressure, especially on European automakers, is increasing, requiring every component in the vehicle to be developed and produced in a cost-optimized manner. Both aspects, along with the environmental requirements for a control unit in automobiles, limit the selection of suitable microcontrollers. It is becoming increasingly important to optimize the use of the limited resources of available hardware to address future technical and regulatory challenges.

This work examines currently available alternatives for Trusted Execution Environments in real-time automotive systems. Furthermore, it considers the new requirements for vehicles that are relevant to the tasks of a TEE, particularly the continuous expansion of functionality in already delivered vehicles (in the context of the Software-Defined Vehicle) and crypto-agility. Following these considerations, a concept will be presented that addresses future challenges for TEEs. This concept provides an approach to ensure that vehicles developed today and produced tomorrow will remain safe and secure for years to come.

Trusted Execution Environment

A Trusted Execution Environment is a tamper-proof environment that operates on a separated kernel. It guarantees the authenticity, confidentiality, and integrity of the runtime states of the executed code as well as the persistently stored data. Through strict isolation of memory, a dedicated processor core, and peripheral hardware components, security-relevant applications running in the TEE can operate entirely independently from the host environment. Cyberattacks on the host environment do not affect the TEE due to this strict separation [2].

Hardware Security Module

A Hardware Security Module (HSM) is typically integrated as an isolated co-processor within a microcontroller and features specialized modules such as a random number generator, symmetric encryption, hash modules, and asymmetric cryptography (e.g., ECDSA) [3]. It is designed to support security functions like secure boot, tamper protection, immobilizer, and authentication. The HSM firmware operates independently of the host system. Communication with the host occurs via dedicated interfaces, with the HSM itself protected against unauthorized access [4]. The co-processor running the HSM is generally significantly less performant than the main processor cores.

According to EVITA (E-safety Vehicle Intrusion Protected Applications), HSMs can be divided into three classes – small, medium, and full. The following table provides an overview of the functionalities assigned to the HSM classifications. The differences in complexity and functionality serve scalability and cost optimization in the development and deployment of HSMs [5].

Trusted Platform Module

The discrete Trusted Platform Module (TPM) is a separate chip installed on the control unit (ECU) and connected to the microcontroller via an external bus system like SPI or I²C. The installation of the TPM is optional, which can be advantageous when, for example, a variant is needed to comply with trade restrictions for certain features. Compared to the Hardware Security Module (HSM), the TPM offers a reduced range of functions. It allows key generation and storage and features a True Random Number Generator (TRNG) as well as secure storage [6]. The TPM can perform cryptographic computations but is not as efficiently usable as an HSM due to the slower connection via an external bus system. An additional disadvantage of the external interface is that it is more vulnerable to attacks compared to an interface within the microcontroller.

ARM TrustZone

The ARM TrustZone technology is a hardware concept for ARM-based microcontrollers that enables secure and non-secure execution of software. It employs two separate register sets and stacks to separate secure and non-secure processing. TrustZone is an optional feature available in selected derivatives, such as the Cortex-M33. It allows for the segregation of memory and peripherals into secure and non-secure enclaves. The connection between these enclaves is managed via a monitor, which facilitates controlled communication between the secure and non-secure areas [2] [7]. As the name suggests, ARM TrustZone is only available on ARM processors; however, it offers excellent scalability for secure runtime environments.

Classic Requirements for the TEE in Automotive

TEEs in real-time control units already fulfill a variety of requirements that need to be implemented in the automotive sector. The following table provides an overview of these "classic" functions.

Requirements in the Software Defined Vehicle

Future vehicle developments are increasingly focusing on software-implemented functionalities to define the customer experience. A prerequisite for this is the ability to update software even in vehicles that have already been delivered. This allows both new functionalities to be deployed in the field and updates to fix, for example, errors in delivered software.

To ensure that this does not become a disadvantage for the customer (frequent workshop visits), the software is updated over-the-air (OTA), meaning in a vehicle already in the field. This type of software update introduces new security risks, which must be mitigated through appropriate security functions (secure update).

Crypto-Agility

According to expert estimates, powerful quantum computers capable of breaking current cryptographic methods could be available within ten years. For this reason, NIST launched a standardization process in 2017 to develop quantum-computer-resistant cryptographic methods (Post-Quantum Cryptography—PQC). In a lengthy, multi-stage selection process, five such algorithms have been selected so far, four of which have already been standardized [10] [11]. Whether there will be additional stages in the selection process and whether the standardized methods will permanently withstand the threat posed by quantum computers remains uncertain at this time.

Vehicles developed or delivered today will still be in operation in 10 years and are therefore potentially vulnerable to quantum computer attacks. The lack of hardware support for and experience with PQC methods, along with the unpredictable advancements in quantum computer development, highlights a requirement that has so far been largely overlooked in the automotive industry—crypto-agility. This demands: "Particular attention should be paid to designing cryptographic mechanisms as flexibly as possible, so as to respond to developments, implement upcoming recommendations and standards, and potentially replace algorithms in the future that no longer guarantee the desired level of security" [12].

The property already demanded in 2021 by the Federal Office for Information Security (BSI) should "become a design criterion for new products—regardless of the development of quantum computers" [12]. Crypto-agility in vehicles can only be implemented in software with reasonable maintenance effort, as a widespread hardware replacement in the automotive market would be cost-intensive and must absolutely be avoided.

Resource Requirements

The previously described future requirements (secure updates, crypto-agility) and other aspects (e.g., GDPR-compliant data protection) increase the resource demand for security-relevant functionalities in vehicles. The software implementation of PQC algorithms alone is hardly conceivable in current hardware-based TEEs, as the computational power and memory requirements have increased significantly compared to previous cryptographic algorithms [13]. However, it is not only the absolute resource requirements but also their scalability that will become even more crucial in the future. When new functions are added to a vehicle and the TEE reaches its performance limits due to limited resources, this limit must be flexible.

Firmware Security Module—a Concept for the Future

As an alternative to the previously presented implementations of TEEs, a concept will now be considered that addresses both the classic requirements and the new challenges. The Firmware Security Module (FSM) implements all necessary security-relevant functionalities required in the control unit. Due to its modular architecture, these functionalities are scalable, and the scope of the FSM can be adapted to the specific needs of a particular system.

The communication of the FSM to the host system runs through the Bridge Module. Here, requests to the FSM are received, verified, and forwarded to the Activity Manager. To prevent inferences about the internal states of the FSM, the Bridge Module also ensures that the response times to requests are always constant [14] [15].

The pure software implementation eliminates most hardware dependencies, allowing the FSM to run on a high-performance CPU core of a multi-core system (see image). This provides the FSM with significantly more computing power and memory. The software-based separation from the insecure environment also enables further scalability of resources for the FSM, such as allocating a second CPU core or additional memory. However, the increased independence from hardware components does not come without disadvantages. For instance, the allocated memory must be protected at system startup using a Memory Protection Unit (MPU), meaning the FSM must necessarily run on the first starting CPU core (usually Core 0). Additionally, useful hardware components for classical cryptography, typically integrated in the HSM, cannot be utilized, such as hardware accelerators for cryptographic algorithms or a true random number generator.

The following table provides an overview of the strengths and weaknesses of the presented TEE variants. It becomes clearly evident that the FSM offers advantages precisely where hardware-bound TEEs reach their limits. However, these also remain justified and are significantly superior in classical cryptography and features that perform better with hardware support.

This article introduced the future challenges for Trusted Execution Environments and examined how current hardware-bound TEEs can address them. As an alternative, the Firmware Security Module was presented, which implements the same requirements in software, thereby taking a completely different approach. It places much greater emphasis on scalability of resources, hardware independence, and updateability. These are features that TEEs urgently need to fulfill due to expected changes in technology, legislation, and development priorities in the automotive sector. However, the weaknesses of the FSM, such as the lack of a true entropy-based random number generator, also demonstrate that hardware support cannot be completely abandoned. A combined use of the FSM and classical TEE could be a possible solution. (sg)

Bibliography and References

[1] ISO - International Organization for Standardization, "ISO 24089:2023-02".

[2] M. Sabt, M. Achemlal, and A. Bouabdallah, "Trusted Execution Environment: What It is, and What It is Not," in 14th IEEE International Conference on Trust, Security and Privacy in Computing and Communications, Helsinki, Finland, 2015.

[3] Vector Informatik GmbH, "Introducing Hardware Security Modules to Embedded Systems," in Vector E-Mobility Engineering Day, 2017.

[4] A. Hattendorf, A. Raabe, and A. Knoll, "Shared memory protection for spatial separation in multicore architectures," in 7th IEEE International Symposium on Industrial Embedded Systems (SIES’12), Karlsruhe, 2012.

[5] O. Henniger, A. Ruddle, H. Seudié, B. Weyl, M. Wolf, and T. Wollinger, "Securing Vehicular On-Board IT Systems: The EVITA Project," in Joint VDI/VW Automotive Security Conference, Ingolstadt, 2009.

[6] "Trusted Platform Module (TPM)," Trusted Computing Group, [Online]. Available: https://trustedcomputinggroup.org/work-groups/trusted-platform-module/. [Accessed 10 2025].

[7] ARM Limited, "ARM Security Technology Building a Secure System using TrustZone Technology," [Online]. Available: https://developer.arm.com/documentation/PRD29-GENC-009492/latest/. [Accessed 10 2025].

[8] C. Pott, P. Jungklass, D. J. Csejka, T. Eisenbarth, and M. Siebert, "Firmware Security Module," Journal of Hardware and Systems Security, 2021.

[9] M. Wolf and T. Gendrullis, "Design, Implementation, and Evaluation of a Vehicular Hardware Security Module," in Information Security and Cryptology - ICISC 2011, 2011.

[10] P. Jungklass, M. Manthe, and D. J. Csejka, "Post-Quantum-Kryptographie auf eingebetteten Steuergeräten," in Embedded Software Engineering Kongress, Sindelfingen, 2024.

[11] P. Jungklass, C.-P. Stöber-Schmidt, R. Barg, H. Hansen, and M. Siebert, "Post-Quantum Cryptography on Embedded ECUs," in 2024 JSAE Annual Congress (Spring), 2024.

[12] Bundesamt für Sicherheit in der Informationstechnik (BSI), "Kryptografie quantensicher gestalten," December 2021. [Online]. Available: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Broschueren/Kryptografie-quantensicher-gestalten.pdf?__blob=publicationFile&v=6.

[13] P. Jungklass, Contribution to the Optimization of Static Memory Management in Embedded Multicore Systems with Hard Real-Time Requirements, Lübeck: University of Lübeck, 2025.

[14] P. Jungklass, C.-P. Stöber-Schmidt, M. Siebert, J. Rummel, and T. Nigoro, "Firmware Security Module," in 2025 JSAE Annual Congress (Spring), 2025.

[15] P. Jungklass and R. Barg, "Firmware Security Module - Security Over the Entire Lifecycle?," in Embedded Software Engineering Kongress, Sindelfingen, 2023.

[16] P. Jungklass, "Firmware Security Module," in 4th Charter of Trust Meetup Braunschweig, Braunschweig, 2024.

This contribution comes from the conference proceedings of the ESE Congress 2025.

*Dipl.-Ing. (FH), M. Sc. Martin Manthe studied computer science at the University of Applied Sciences Stralsund and has been working as a development engineer in the embedded software field for many years. At the start of his career, he developed basic software components for various control units for different OEMs in the automotive sector. After an extended period as a developer in the aviation sector, he is currently working on various security-relevant applications (again in the automotive sector).