Microcontroller Integrity Checking with Security Attribution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current systems for integrity checking in mixed security microcontrollers cannot perform integrity checks across secure and non-secure memory regions without compromising intellectual property, as they rely on fixed addresses and are susceptible to data leakage attacks due to configurable security settings.
Innovation Solution
A microcontroller with a security attribution unit and an integrity checking unit that stores integrity check tables in memory regions, allowing secure integrity checks by determining if the check table and code are in the same region and adhering to security attributes, thus preventing unauthorized access and data leakage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If integrity checks are performed on code in secure memory regions, then integrity verification capability is improved, but intellectual property confidentiality is compromised
Solution Approach 1:
The memory system is segmented into secure and non-secure regions, with integrity check tables stored in non-secure regions and code in secure regions. This segmentation allows integrity verification without exposing confidential code, as the check tables contain only metadata (addresses, sizes, expected hash values) rather than the actual code content.
Solution Approach 2:
Integrity check tables serve as intermediaries between the integrity checking unit and the secure code. These tables store reference information (starting addresses, sizes, expected hash values) that enable verification without direct access to the confidential code, acting as a mediator that preserves confidentiality while enabling verification.
2Adaptability or versatility
If security settings are made configurable by code providers, then adaptability is improved, but system security is worsened due to potential data leakage attacks
Solution Approach 1:
Security attributes are applied locally to individual memory regions rather than uniformly across the entire memory space. Each memory region can have its own security attribution (secure or non-secure), allowing code providers to protect only specific regions containing confidential code while allowing other regions to be accessible for integrity verification purposes.
3Device complexity
If integrity check tables are stored in the same memory regions as code, then device complexity is reduced, but security is worsened due to inability to perform checks across secure boundaries
Solution Approach 1:
The system segments memory into distinct secure and non-secure regions with different purposes. Non-secure regions store integrity check tables and metadata, while secure regions store confidential code. This segmentation resolves the contradiction by allowing check tables to be stored separately from code, enabling cross-region integrity verification while maintaining security boundaries.
Data Source
AI summary
A microcontroller configured to provide secure integrity checking of code or data stored in the microcontroller is provided. The microcontroller may include a processor, memory devices defining a microcontroller memory space, a security attribution unit defining secure memory region(s) and non-secure memory region(s) in the memory space, integrity check tables indicating storage locations of various code within the microcontroller memory space, and an integrity checking unit. The integrity checking unit may be configured to receive an integrity check request for checking the integrity of a first piece of code stored in the microcontroller memory space, access a first integrity check table that indicates a storage location of the first piece of code, determine whether the first integrity check table and first piece of code are stored in the same memory region; and determine whether to perform the requested integrity check based at least on this determination.