Securing In‑Cabin AI with a Trusted Execution Environment on a Secure FPGA SoC

This article demonstrates how a Trusted Execution Environment (TEE) combined with a secure FPGA SoC can protect in‑cabin AI systems in modern vehicles.

Part I of this series, "Trusted Execution Environments in Connected Cars," explained that while TEEs are ubiquitous on smartphones, their adoption in automotive systems remains limited. The absence of a TEE can expose critical vehicle functions to attack. In Part II we focus on in‑cabin AI as a case study and show how a contemporary TEE and FPGA SoC form a robust security foundation.

Typical In‑Cabin AI System

In‑cabin AI, a key component of advanced driver‑assist systems (ADAS), is more widely deployed than full autonomous driving. Using cameras or other sensors, it delivers contextual safety guidance and supports intuitive controls such as voice and gesture. For example, inward‑facing cameras monitor truck drivers for signs of inebriation, distraction, drowsiness, or fatigue, alerting them to prevent accidents. This technology is already common in commercial fleets and is gradually permeating consumer vehicles to enhance driver safety. AI‑powered cameras can also detect when children or pets are left unattended, mitigating heat‑related risks.

A typical in‑cabin platform tracks driver behavior, verifies seatbelt usage, and can be trained to identify objects of interest—cell phones, keychains, infant seats, and more. It must perform machine‑learning inference on video streams, communicate with other ECUs (e.g., central ADAS or infotainment), and support secure firmware upgrades. Additional functions include blind‑spot detection via side‑rear‑view cameras and offloading in‑vehicle network (IVN) authentication from the central ADAS.

Hardware Hardening Example

Microchip’s PolarFire SoC FPGA exemplifies a platform capable of integrating mixed‑criticality workloads. It delivers efficient ML inference on FPGA fabric while the quad‑core RISC‑V processor subsystem handles control and monitoring tasks. The system supports a deterministic RTOS alongside a power‑efficient Linux distribution, as illustrated in Figure 1.

Figure 1. PolarFire SoC In‑Cabin AI Platform. ML inference runs on FPGA fabric. RISC‑V SoC hosts control and monitoring functions.

The PolarFire SoC incorporates hardware security features such as tamper‑proof packaging, differential‑power‑analysis (DPA) countermeasures, and secure boot via a SECDED‑enabled 128‑kB boot flash. These measures protect the device from side‑channel attacks, prevent bitstream cloning, and allow carmakers to restrict FPGA programming to authorized units.

Protection of AI Inference Models and Data Assets

Critical data assets on this platform include:

• IVN (CAN bus) – unauthorized access could compromise vehicle control.
• Driver and passenger PII – must be kept confidential for privacy compliance.
• OTA code and data – must resist corruption or hijacking.
• AI inference models – vulnerable to intellectual property theft or model‑poisoning attacks.
• Cryptographic secrets – essential for authenticating IVN messages.

Designing for confidentiality, integrity, and availability (CIA) is essential to safeguard these assets. Typical attack surfaces and threats include:

Attack Surface	Potential Exploit
Application and Network Layers	Malware or buffer‑overflows targeting IVN, OTA, or PII leakage.
Rich OS	Linux’s expansive surface can allow system compromise or covert intrusion.
Sensors	Model hacking or adversarial ML via memory access, leading to erroneous ADAS behavior.
Sensors	Surrogate model inversion – an attacker can reconstruct the inference model from input‑output observations.

Implementing a Trusted Execution Environment

A TEE that enforces security‑by‑separation is a powerful countermeasure for a zero‑trust architecture. Hex Five’s MultiZone® Security, for instance, leverages memory‑partition primitives (PMP on RISC‑V, MPU on ARM) and CPU privilege levels to create isolated zones. On the PolarFire SoC, MultiZone partitions the system into five secure containers, as shown in Figure 2.

Figure 2. MultiZone creates five zones on PolarFire SoC. Only MultiZone operates in M‑mode (CPU Ring 0 on RISC‑V); each red box denotes a software‑defined, hardware‑separated zone.

The five zones are:

1. OTA – protects the CIA of over‑the‑air updates.
2. Camera – secures sensor data streams.
3. IVN Authentication – functions like an HSM, safeguarding cryptographic keys and signatures.
4. RTOS – controls IVN traffic.
5. Linux Enclave – contains faults originating from the operating system.

This configuration demonstrates how a TEE, together with hardened hardware, establishes a foundational secure platform for in‑cabin AI.

TEE as a Foundational Security Layer

A robust automotive security posture should include at least the following layers:

• Application‑level security controls.
• Intrusion Detection/Prevention System (IDPS) for network traffic.
• Secure OTA mechanisms.
• Trusted Execution Environment.
• Hardware with built‑in security primitives and a root of trust.

Incorporating TEEs into vehicles parallels the protection found in modern smartphones, offering a pathway to higher vehicular security.

This article was co‑authored by Diptesh Nandi of Microchip.

Industry Articles provide partners an avenue to share technical insights with All About Circuits readers. These articles adhere to strict editorial guidelines and reflect the partner’s viewpoints, not necessarily those of All About Circuits.