An Example of Securing In-Cabin AI using TEE on a Secure FPGA SoC
This article discusses trusted execution environments — already used in a variety of connected devices — by showing how using TEE and an FPGA SoC can work in vehicle in-cabin AI.
Part I to this article, Trusted Execution Environments (TEEs) in Connected Cars, discussed that while a Trusted Execution Environment (TEE) is widely used on mobile phones and other connected devices to secure critical functions, adoption in connected vehicles is low. The lack of TEE can create system vulnerabilities. In Part II we will take in-cabin AI as an example application, and discuss how a modern TEE and FPGA SoC can be its secure platform.
Typical In-Cabin AI System
In-cabin AI is part of an advanced driver assistance system (ADAS) and is, in fact, more popularly deployed than autonomous driving. In-cabin AI leverages cameras or other sensors to give drivers and passengers contextual safety guidance, or provide options such as voice, gesture to control the vehicle. For instance, inward-facing cameras are adept at monitoring truck drivers to detect inebriation, distraction, drowsiness, and fatigue to alert the driver and prevent accidents. These are currently widely deployed in commercial vehicles and trucks. The same technology is beginning to penetrate consumer vehicles to observe driver-related behavior for safety purposes. AI-powered cameras also can alert when children and pets are left in the vehicle to avoid heat-related deaths.
A typical in-cabin system monitors driver behavior, checks whether occupants are wearing seatbelts and can be trained to track objects of interest like cellphones, keychains, baby seats, etc. The system needs to accomplish many functions including machine learning-based video signal chain, communication with other ECUs like the central ADAS or the infotainment system, and support firmware upgrades.
It can also perform blind spot detection — side rear-view mirrors augmented with small-form-factor cameras can be used to run ML algorithms to spot vehicles in driver’s blind spot. Additionally, it can offload processing such as in-vehicle network (IVN) authentication from the central ADAS.
An Example of Hardened Hardware
Microchip’s PolarFire SoC FPGA is an example of hardware that can support this kind of consolidated functions, mixed-criticality system. It enables in-cabin AI applications with efficient inferencing on the FPGA fabric and microprocessor subsystem to run control and monitoring jobs. It supports deterministic RTOS along with rich Linux on highly power-efficient quad-core RISC-V processors (see Figure 1).
Figure 1. PolarFire SoC In-Cabin AI Platform. ML inference runs on FPGA fabric. RISC-V SoC hosts control and monitoring functions.
To harden the hardware, PolarFire SoC has built-in security measures that include tamperproof support plus differential-power-analysis (DPA) countermeasures. This protects the chip against side-channel exploits that are aimed at extracting bitstreams and thus prevents cloning. Using the secure programming infrastructure, a carmaker has full control on the number of FPGAs that can be programmed, thereby protecting against overbuilding. PolarFire SoC also supports secure boot using a SECDED enabled onboard secure 128-kB boot flash memory.
AI Inference Model and Other Valuable Data Assets Must Be Protected
On this system, valuable data assets include:
- IVN – unintended access to the IVN (“CAN bus”) can allow an adversary to take over the vehicle
- Driver and passenger personal identifiable information (PII) – PII should be hidden for consumer privacy
- OTA – if OTA code or data is corrupted or hijacked, bad or malicious firmware can be injected
- AI model – inference model is susceptible to IP theft and attack
- Secrets – Keys and crypto libraries must be shielded to ensure digital signature algorithm (DSA) of IVN messages
The confidentiality, integrity, and availability (CIA) of these assets must be considered during design.
Attack surfaces and threats to these assets include:
| Attack Surfaces | Exploits |
| Application and Network Layers | Malware, buffer-overflow to exploit IVN, OTA, steal PII |
| Rich OS | A rich OS such as Linux has a large attack surface. Any non-free firmware also introduces opaqueness and risks. Exploits can take down the entire system or can enable an adversary to silently enter through the rich OS to manipulate other assets. |
| Sensors | “Model Hacking” or “Adversarial Machine Learning” is when the sensor memory is accessible by untrusted applications, malware can perturbate the sensor memory, resulting in unintended operation of ADAS. |
| Sensors | “Inversion by Surrogate Model”: When an adversary can control the input and observe the output of the inference model by being able to read and write to memory, he can re-create the model. He could use that copy to learn trends and distributions in the training data or to plan future attacks. |
An Example of a Trusted Execution Environment
A TEE which provides security-by-separation is an excellent countermeasure to design a zero-trust model to safeguard these data assets.
A TEE that takes a new approach is Hex Five’s MultiZone® Security. It makes use of memory partition primitives: “physical memory protection” PMP which is standard on all RISC-V or “memory protection unit” MPU on Arm®, and privilege levels in the CPU (M-mode and U-mode for RISC-V, Handler and Thread levels for Arm®) to create multiple secure containers or zones.
A configuration of MultiZone on PolarFire SoC can look like Figure 2. Each red box indicates a functional block protected in a “container” or a “zone”. Within each zone, only authorized and assigned code can access specified memory regions according to read-write-execute permissions set up by a MultiZone policy file. Interrupt handlers are assigned to a zone so that it only runs with user-mode privilege instead of kernel mode, to comply with the zero-trust model.
The five zones are:
- OTA– Protects the CIA of OTA code and data
- Camera - Secures camera sensor data
- IVN Authentication – Similar to an HSM, this zone secures the keys and crypto for DSA
- RTOS – Controls the IVN
- Linux Enclave – Faults from Linux will be contained
These zones are shown in Figure 2.
Figure 2. MultiZone creates 5 “zones” on PolarFire SoC. Only MultiZone runs in M-mode which is CPU Ring 0 on RISC-V. Each red box is a software-defined, hardware-separated zone.
This example configuration shows how a TEE and its companion hardware create a foundational secure platform for an in-cabin AI application.
TEE is a Foundational Layer
A good security posture for connected vehicles should include at the minimal:
- Application security
- Intrusion Detection Prevention System (IDPS) for network security
- Secure OTA
- Trusted Execution Environment
- Hardware with built-in security primitives, root-of-trust
Underpinning TEEs to our vehicles is critical, no different from having TEEs in our phones. That is a path to making our cars more secure than our smartphones.
This article was co-authored by Diptesh Nandi, of Microchip.
Industry Articles are a form of content that allows industry partners to share useful news, messages, and technology with All About Circuits readers in a way editorial content is not well suited to. All Industry Articles are subject to strict editorial guidelines with the intention of offering readers useful news, technical expertise, or stories. The viewpoints and opinions expressed in Industry Articles are those of the partner and not necessarily those of All About Circuits or its writers.
