Unified Crypto Interface for TEE-Aware Vehicle Control

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing control device applications face complexity and inefficiency due to the need to distinguish between cryptographic operations within and outside a trusted execution environment (TEE), requiring separate APIs and advanced security knowledge, which complicates development and increases memory and runtime costs.

Innovation Solution

A control device with a processor circuit and a trusted environment hardware module, utilizing an interface module that abstracts cryptographic service functions through local and external implementations, providing a unified API to handle operations within and outside the TEE without requiring application adaptation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If cryptographic operations are performed inside the TEE, then security is improved, but memory consumption and runtime increase

Engineering Contradiction:
ImprovesecurityVSAvoidruntime efficiency
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The cryptographic service functions are segmented into two categories: those requiring TEE execution (for security-critical operations involving confidential material) and those that can execute outside the TEE (for non-critical operations). This segmentation allows the system to optimize each category appropriately, running secure operations in the TEE and performance-critical operations outside, thereby resolving the contradiction between security and runtime efficiency.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system dynamically determines whether to execute cryptographic operations inside or outside the TEE based on the specific operation type and security requirements. The interface module provides adaptive routing that switches between TEE and non-TEE execution paths, allowing the system to maintain security where needed while optimizing performance where possible, thus resolving the static trade-off between security and efficiency.

Inventive Principle:
Principle #15Dynamics

2Reliability

If separate APIs are used for TEE and non-TEE operations, then security control is improved, but application complexity increases

Engineering Contradiction:
Improvesecurity controlVSAvoidapplication complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The interface module serves as an intermediary layer between the application and the underlying TEE/non-TEE execution environments. It provides a unified API that abstracts the complexity of separate TEE and non-TEE interfaces, automatically routing operations to the appropriate execution environment based on security requirements. This mediator approach maintains security control while shielding applications from complexity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The interface module implements a universal API that handles both TEE and non-TEE operations through a single interface. This multi-functional interface consolidates what would otherwise require separate API sets, allowing applications to interact with both secure and non-secure cryptographic operations through one unified interface, thereby reducing application complexity while maintaining security distinctions.

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

3Reliability

If applications have advanced knowledge about security architectures, then security implementation is improved, but ease of manufacture decreases

Engineering Contradiction:
Improvesecurity implementationVSAvoidapplication development ease
Core Design Contradiction:
ReliabilityVSEase of manufacture

Solution Approach 1:

The interface module implements self-service by automatically determining which cryptographic operations require TEE execution and which can run outside, without requiring applications to have knowledge of security architectures. The system autonomously analyzes operation requirements and routes them appropriately, eliminating the need for developers to understand complex security distinctions while maintaining proper security implementation.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The interface module acts as an intermediary that shields applications from security architecture complexities. It translates high-level cryptographic operation requests into appropriate TEE or non-TEE execution paths without requiring applications to understand the underlying security model, thereby improving ease of manufacture while maintaining security implementation quality.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentEP4460777B1Control device comprising a processor circuit for executing applications that use cryptographic service functions and method for operating the control device and motor vehicle
Publication Date: 2026.04.08 CARIAD SE
  • EP4460777B1 patent drawingFigure 1
  • EP4460777B1 patent drawingFigure 2a
  • EP4460777B1 patent drawingFigure 2b

AI summary

The invention is concerned with a control device (11) comprising a processor circuit (14) for executing applications (15) that use a cryptographic service functions (24) by calling a respective programming interface (30) of the service function (24), wherein the processor circuit (14) is adapted to execute the respective application (15) as a process (32) of the processor circuit (14). According to the invention, the control device (11) comprises a trusted environment hardware module (23) and an interface module (36) is provided that comprises the programming interfaces (30) for calling the service functions (24) and that is adapted to call one of the following implementations of the service function (24) depending on which service function (24) the respective programming interface (30) belongs to: a local implementation (37) that is executable as a part of the process (32) of the calling application (15) or in a parallel process (32) of the processor circuit (14), or an external implementation (38) that is provided by the hardware module (23).