Lightweight Trusted Execution for IoT Devices

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

There is a need for a lightweight secure architecture that provides hardware-based, trusted execution on tiny processors for IoT devices while addressing power and area constraints, and ensuring isolation of software modules from adversaries.

Innovation Solution

A lightweight secure architecture is implemented, which partitions main memory into secure and unsecure domains using policy enforcement logic and secure domain metadata, allowing only secure domains to access their own data and code, with hardware managing domain allocation and deletion to maintain security even if the operating system is compromised.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If hardware-based secure architecture is implemented on tiny processors, then security and isolation of software modules is improved, but power consumption and area overhead increase

Engineering Contradiction:
ImprovesecurityVSAvoidpower consumption
Core Design Contradiction:
ReliabilityVSUse of energy by stationary object

Solution Approach 1:

The memory system is segmented into secure and unsecure domains using domain tags. Each memory access includes a domain tag that is compared against stored domain values in the SDC, enabling fine-grained security control without requiring full MMU complexity. This segmentation approach provides security through domain-based access control while keeping the hardware footprint small.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

Security features are applied locally at the memory access level rather than globally across the entire processor. The policy enforcement logic operates at the interface between the core and main memory, implementing security checks only when needed for memory accesses to secure domains, thereby minimizing overall power consumption while maintaining security where required.

Inventive Principle:
Principle #3Local quality

2Reliability

If hardware-based secure architecture is implemented on tiny processors, then security and isolation of software modules is improved, but device area increases

Engineering Contradiction:
ImprovesecurityVSAvoidarea overhead
Core Design Contradiction:
ReliabilityVSArea of stationary object

Solution Approach 1:

The security functionality is extracted from the main processor core and implemented as a separate policy enforcement logic unit interfacing with main memory. This extraction allows the core to remain simple while security functions are handled by dedicated but compact hardware structures (SDC and PEL), reducing the area overhead on the tiny processor core.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Security is implemented by adding a domain tag dimension to memory addresses rather than creating separate physical memory spaces. This dimensional approach allows multiple secure domains to share the same physical memory space with logical isolation, eliminating the need for large separate memory regions and reducing overall area requirements.

Inventive Principle:
Principle #17Another dimension (Dimensionality change)

3Reliability

If policy enforcement logic with domain tags is used for memory access control, then isolation of secure domains is improved, but access latency increases

Engineering Contradiction:
ImproveisolationVSAvoidaccess latency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Domain tags are preliminarily attached to memory addresses during address generation, and the SDC is pre-loaded with domain value information for secure pages. This preliminary tagging allows the policy enforcement logic to perform simple tag comparisons rather than complex access control checks during actual memory operations, minimizing latency overhead.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

Instead of copying entire page tables or complex access control structures, the system uses compact domain tags (e.g., 4-bit values) that replicate the essential security information needed for access control. This copying of minimal security metadata enables fast comparison operations while maintaining strong isolation guarantees.

Inventive Principle:
Principle #26Copying

4Reliability

If main memory is partitioned into secure and unsecure domains, then security against adversaries is improved, but memory overhead increases

Engineering Contradiction:
ImprovesecurityVSAvoidmemory overhead
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The same main memory space serves both secure and unsecure purposes through domain-based virtualization. The SDC structure allows a single memory region to be dynamically assigned to different secure domains or unsecure regions based on domain tag comparisons, eliminating the need for separate physical memory spaces and reducing overall memory overhead while maintaining security isolation.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS10671744B2Lightweight trusted execution for internet-of-things devices
Publication Date: 2020.06.02 INTEL CORP
  • US10671744B2 patent drawing
  • US10671744B2 patent drawing
  • US10671744B2 patent drawing

AI summary

Lightweight trusted execution technologies for internet-of-things devices are described. In response to a memory request at a page unit from an application executing in a current domain, the page unit is to map a current virtual address (VA) to a current physical address (PA). The policy enforcement logic (PEL) reads, from a secure domain cache (SDC), a domain value (DID) and a VA value that correspond to the current PA. The PEL grants access when the current domain and the DID correspond to the unprotected region or the current domain and the DID correspond to the secure domain region, the current domain is equal to the DID, and the current VA is equal to the VA value. The PEL grants data access and denies code access when the current domain corresponds to the secure domain region and the DID corresponds to the unprotected region.