SoC Configuration File Isolation for Runtime Tamper Protection

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

System-on-chip (SoC) components are vulnerable to attacks during runtime due to unprotected configuration files, which can be modified or tampered with before the trusted execution environment (TEE) is loaded, and lack mechanisms for validation and recovery.

Innovation Solution

The SoC employs a microcontroller unit (MCU) to move configuration files into a secure memory portion and mark it as inaccessible, utilizing an IOMMU to protect the files, and a trusted execution environment (TEE) to validate and restore them.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If configuration files are stored in unprotected memory during runtime, then the SoC can operate with simpler memory architecture, but the configuration files become vulnerable to attackers who can access and modify them

Engineering Contradiction:

Improvememory architecture complexityVSAvoidvulnerability to configuration file modification

Core Design Contradiction:

Device complexityVSObject-affected harmful factors

Solution Approach 1:

The memory is segmented into different protection zones. A first memory portion is designated for storing configuration files of safety-relevant components with restricted access, while a second memory portion serves other purposes. This segmentation allows the system to provide targeted protection to critical configuration files without requiring complete memory reconfiguration.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The IOMMU (Input-Output Memory Management Unit) acts as an intermediary between the configuration files and other system components. It mediates access to the first memory portion by translating memory addresses and controlling access rights, thereby protecting configuration files from unauthorized modification while maintaining system operability.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Device complexity

If the TEE is loaded after safety-relevant components, then the booting sequence can be simplified, but the TEE cannot protect configuration files during runtime

Engineering Contradiction:

Improvebooting sequence complexityVSAvoidconfiguration file security during runtime

Core Design Contradiction:

Device complexityVSReliability

Solution Approach 1:

The system performs preliminary actions by storing configuration files in the first memory portion before the TEE is fully operational. The IOMMU is configured in advance to enforce access restrictions on this memory portion, ensuring that configuration files are protected even during the booting phase when the TEE is not yet loaded.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The memory protection mechanism is dynamic rather than static. The IOMMU dynamically manages access rights to the first memory portion based on the operational state of the TEE and other system components. This allows the system to adapt memory protection policies during runtime without requiring complex booting sequence changes.

Inventive Principle:

Principle #15Dynamics

3Adaptability or versatility

If configuration files are accessible to all components, then system operation is more flexible, but there is no mechanism to validate or detect changes in configuration files

Engineering Contradiction:

Improvesystem operational flexibilityVSAvoiddetection of configuration file changes

Core Design Contradiction:

Adaptability or versatilityVSDifficulty of detecting and measuring

Solution Approach 1:

The system implements feedback mechanisms through the IOMMU that monitor and detect changes in configuration files stored in the first memory portion. When unauthorized modifications are detected, the system can generate alerts or responses to notify relevant components, thereby maintaining detection capability while preserving operational flexibility through controlled access.

Inventive Principle:

Principle #23Feedback

4Productivity

If no memory protection is implemented, then the system can be simpler and faster, but attackers can modify configuration files at runtime without detection

Engineering Contradiction:

Improvesystem operation speedVSAvoidruntime configuration file tampering

Core Design Contradiction:

ProductivityVSObject-affected harmful factors

Solution Approach 1:

Instead of implementing memory protection across the entire memory space, the system applies local quality protection specifically to the first memory portion where configuration files are stored. The IOMMU enforces restricted access rights only for this specific region, allowing other parts of the system to operate without additional overhead while still protecting critical configuration files from runtime tampering.

Inventive Principle:

Principle #3Local quality

Data Source

PatentUS20250371199A1System and method for enhancing security of system-on-chip

Publication Date: 2025.12.04 TOYOTA JIDOSHA KK

AI summary

Example embodiments of the present disclosure provide enhancement on the security of a system-on-chip (SoC). According to embodiments, a method for enhancing the security of the SoC is provided. The method may be performed by at least one microcontroller unit (MCU) implemented in the SoC and may include: accessing a storage component that stores a plurality of configuration files; selecting at least one configuration file from among the plurality of configuration files; moving the at least one configuration file into a portion of a memory component; and marking the portion of the memory component as non-accessible by other components.