{"id":34652,"date":"2026-09-14T05:00:00","date_gmt":"2026-09-14T03:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=34652"},"modified":"2026-08-19T16:42:27","modified_gmt":"2026-08-19T14:42:27","slug":"tpm-2-0-in-automotive","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/tpm-2-0-in-automotive\/","title":{"rendered":"TPM 2.0 in Automotive"},"content":{"rendered":"\n

This article presents an overview of Trusted Platform Module (TPM) technology and its role in automotive systems. This discussion begins by explaining TPM as a hardware-based Root of Trust, designed to securely generate, store, and manage cryptographic keys. It also addresses the differences between the TPMs and Hardware Security Modules (HSMs), highlighting their different roles within vehicle architectures.<\/p>\n\n\n\n

The article further describes the need to update the TPM standard (from 1.2 to 2.0) and summarizes key features, emphasizing cryptographic agility, flexible authorization mechanisms, and enhanced support for secure boot and attestation. Additionally, it provides some practical knowledge by presenting TPM hardware solutions, relevant software stacks, and real-world automotive use cases, including secure firmware updates and key storage.<\/p>\n\n\n\n

However, let’s start by explaining what a TPM is.<\/p>\n\n\n\n

What is TPM (Trusted Platform Module)?<\/strong><\/strong><\/h2>\n\n\n\n

A Trusted Platform Module (TPM) is a dedicated hardware security component designed to provide a hardware-based Root of Trust for a system \u2013 a source that can always be trusted. Its role is to generate, store, and securely manage cryptographic keys. In addition, it performs security-critical operations such as encryption, decryption, digital signing, and integrity measurements in an isolated environment that is resistant to tampering.<\/p>\n\n\n\n

It is worth highlighting that a TPM is not a cryptographic accelerator, as it is not designed for high-throughput or performance-critical cryptographic operations. In automotive systems, TPMs are used to protect vehicle ECUs, secure in-vehicle and external communications, support secure boot, safeguard sensitive data throughout the vehicle lifecycle, and especially protect over-the-air (OTA) updates.<\/p>\n\n\n\n

\"Key\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Fig. 1 Key features of TPM (Figure created by the author)<\/figcaption><\/figure>\n\n\n\n

TPM vs HSM<\/strong><\/strong><\/h2>\n\n\n\n

In Automotive systems, the most used hardware modules for enabling cybersecurity and performing cryptographic operations are TPM and HSM. While both Trusted Platform Modules and Hardware Security Modules provide hardware-based security and protected key storage, they are designed for different roles within a system.<\/p>\n\n\n\n

A TPM is intended to act as a Root of Trust for a single endpoint platform<\/strong>, focusing on integrity measurement, secure boot, device identity, and attestation. Architecturally, TPMs are deployed on higher-level components such as gateways or infotainment systems, operating alongside robust operating systems like Linux or QNX.<\/p>\n\n\n\n

In contrast, while Hardware Security Modules (HSMs) are also utilized for secure boot and authenticity, they are optimized for high-performance cryptographic operations and key management across embedded, real-time systems. This allows HSMs to support a wider range of algorithms, higher throughput, and concurrent operations for multiple real-time applications.<\/p>\n\n\n\n

In automotive systems, HSMs are commonly integrated directly into microcontrollers to secure real-time functions such as message authentication and encryption on vehicle networks. At the same time, TPMs are typically used alongside the main processor to establish system trust or to support secure lifecycle operations such as provisioning and over-the-air updates.<\/p>\n\n\n\n

Features of TPM 2.0<\/strong><\/strong><\/h2>\n\n\n\n

The previous TPM standard (1.2) relied heavily on the SHA-1 algorithm, embedding it in the architecture. Cryptographic vulnerabilities exposed by Xiaoyun Wang’s 2005 SHA-1 collision attack paper forced the Trusted Computing Group to redesign its standards around algorithm agility. TPM2.0 is no longer limited to fixed cryptographic operations. Instead, it supports multiple configurable algorithms, including SHA-2, SHA-3, and the ECC family \u2013 such as ECDH and ECDSA – allowing systems to adapt to evolving security requirements.<\/p>\n\n\n\n

What is more, TPM 2.0 introduces more flexible authorization mechanisms that can enforce multiple conditions for accessing protected resources. Not only are user-defined passwords and cryptographic proofs required, but the system also needs to be in a known, trusted state. This is achieved by special registers inside the TPM (Platform Configuration Registers), which extend and store hashes of each stage of the boot sequence, creating a chain of trust. Since the hash changes if any component is modified, PCR values may be used as a safeguard for controlling access to protected keys.<\/p>\n\n\n\n

TPM 2.0 also incorporates a defensive mechanism against brute force attempts to guess authorization values such as PINs or passwords. Hardware tracks failed authorization attempts and temporarily locks access to protected functions or data once the defined threshold is exceeded. The lockout mechanism requires time delays, which may include exponential backoff or special administrative credentials to reset.<\/p>\n\n\n\n

The application of TPM 2.0<\/strong><\/strong><\/h3>\n\n\n\n

I have already mentioned that TPM is mainly intended to act as a Root of Trust. But where does this trust come from? First of all, the chip itself is tamper-resistant and is isolated from the main CPU. By design, private keys generated inside the TPM never leave the device. This means that keys are physically protected, not just secured by software. Most importantly, TPM vendors may provision each TPM with a unique Endorsement Key and correlated certificates before shipping it to the end user. During the manufacturing process of an ECU, each certificate can be verified to ensure that it is signed by a trusted Certificate Authority (CA) of the TPM vendor.<\/p>\n\n\n\n

It is important to note that a TPM is not a cryptographic accelerator and may be slower than some software implementations. However, this is typically not a concern when used in early boot stages or in scenarios where certified cryptographic implementations are required.<\/p>\n\n\n\n

These features make TPM 2.0 more scalable, future\u2011proof, and well aligned with automotive security needs such as secure provisioning, lifecycle management, and over-the-air updates.<\/p>\n\n\n\n

Software stacks that can be used with TPM2.0<\/strong><\/strong><\/h2>\n\n\n\n

Several software libraries and stacks are available to interface with TPM 2.0 hardware and perform cryptographic operations, attestation, and key management:<\/p>\n\n\n\n