Driving Secure: The Automotive Cybersecurity

As the automotive future is dominated by software-defined and autonomous vehicles, the electronic architecture of cars is undergoing a profound transformation. The traditional model of numerous standalone ECUs is giving way to Zonal and Centralized Architectures, where powerful domain controllers and high-performance computers (HPCs) orchestrate vehicle functions.

This evolution simplifies complexity, enables advanced capabilities like ADAS, and fosters continuous innovation. However, greater computing power also brings heightened cybersecurity challenges. Centralized computing introduces new attack surfaces, making robust protection essential.

This session explores how Hardware Security Modules (HSMs), Trusted Platform Modules (TPMs), and Secure Elements form the backbone of this defense. We will examine their roles in:

• Ensuring secure boot processes
• Safeguarding Over-the-Air (OTA) updates
• Mitigating emerging cyber threats

Finally, I'll shed some light on leveraging AI for Post-Quantum Cryptography (PQC) specifically for bootloaders, preparing vehicle security for the next generation of computing challenges.

What this presentation is about and why it matters

How do you secure a vehicle that is becoming more connected, more software-driven, and harder to update safely over its lifetime? Gunjan Vora approaches that question with a practical overview grounded in automotive development, from the move to software defined vehicles and service oriented architecture to the mechanics of secure boot, secure flash, and secure onboard communication. The talk also looks at the standards and regulations shaping the field, then opens the door to post quantum cryptography and why it is entering automotive planning now. It is a useful watch for anyone trying to connect architecture, compliance, and implementation work.

Who will benefit the most from this presentation

• Automotive embedded engineers who are moving from ECU-centric systems to centralized or zonal architectures
• Security engineers who need a vehicle-level view of secure boot, update, and communication flows
• Firmware developers working on OTA updates, bootloaders, or signing pipelines
• Technical leads who need to map cybersecurity goals to standards and implementation choices
• Engineers evaluating post quantum cryptography for long-lived embedded systems

What you need to know

A basic understanding of embedded systems and automotive software helps. It is especially useful to already know:

• What an ECU is and how in-vehicle networks work at a high level
• Core cryptography terms like encryption, hashing, digital signatures, and MACs
• The idea of a boot chain and firmware verification
• General awareness of OTA updates and vehicle software lifecycle concerns

Glossary (terms used in this talk)

• TrustZone: ARM technology that provides hardware-based isolation between secure and non-secure execution environments.
• HSM (Hardware Security Module): A dedicated hardware component used to protect cryptographic keys and perform security-sensitive operations in isolation. It is commonly used to anchor trust in secure boot and key management workflows.
• SUMS (Software Update Management System): An organizational and technical system for controlling vehicle software updates across the product lifecycle. It helps manage release, validation, deployment, and traceability for updates that affect vehicle behavior.
• CSMS (Cybersecurity Management System): A management system for identifying, assessing, and handling cybersecurity risks across a product or organization. It is typically used to support governance, monitoring, and incident response obligations.
• SECOC (Secure Onboard Communication): A communication protection approach that adds authentication and freshness protection to messages sent between embedded nodes. It is used to help detect tampering and replay in constrained networks.
• MAC (Message Authentication Code): A short cryptographic tag that lets a receiver verify a message has not been altered and was produced by a party holding the shared secret. It is commonly used to protect in-vehicle and embedded communications against tampering and forgery.
• AUTOSAR: AUTOSAR is a standard software architecture for automotive ECUs that defines common interfaces, services, and runtime environments for automotive software components.
• UEFI: UEFI (Unified Extensible Firmware Interface) is a modern firmware interface for platform initialization and booting that supports signed firmware and secure boot mechanisms.

Toolbox (mentioned in this talk)

• GitHub: A web-based platform for hosting Git repositories and collaborating on software development.
• STM32U575ZI-Q: A microcontroller development board based on an Arm Cortex-M33 MCU, often used for prototyping secure embedded software. It provides a practical target for measuring boot-time and memory impact on resource-constrained hardware.
• STM32U5: A microcontroller family aimed at low-power embedded applications with security features such as TrustZone support on selected parts. It is used as a platform for evaluating secure boot and cryptographic workloads.

Final thoughts

Practical and forward-looking, this session moves between architecture, policy, and boot-time implementation with an engineer’s eye for tradeoffs. Viewers will come away with a clearer mental model for how automotive security hangs together across secure boot, update paths, and in-vehicle communication, plus a more grounded vocabulary for post quantum migration. It will help firmware developers, automotive security engineers, and technical leads who need to connect compliance goals to real embedded design choices. The lasting value is the bridge it builds between what must be protected and how that protection actually fits into a vehicle program.

This overview is AI-generated from the session transcript. Spot an issue? Let us know.