Thread Ownership for Hardware Cryptographic Keys

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Conventional processor architectures are vulnerable to attacks on cryptography keys during multithreading operations, as malicious software can intercept and misuse encryption keys stored in secure memory, lacking adequate key ownership verification.

Innovation Solution

Each key entry in the secure memory is bound to a specific thread using a thread owner field, ensuring that only the thread that provisioned the key can access and use it, preventing unauthorized access and misuse.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If keys are stored in secure memory accessible by the co-processor during multithreading operations, then cryptography operations can be performed efficiently across multiple threads, but the system becomes vulnerable to attacks where malicious software can intercept and misuse encryption keys

Engineering Contradiction:
Improvecryptography operation throughputVSAvoidkey interception and misuse vulnerability
Core Design Contradiction:
ProductivityVSObject-affected harmful factors

Solution Approach 1:

The key storage structure is segmented to include separate fields: a key identifier field for accessing the key, a thread owner field indicating which thread owns the key, and the actual key data. This segmentation allows the system to verify thread ownership before key access, preventing unauthorized use while maintaining efficient access for authorized threads

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

A thread ownership verification mechanism acts as an intermediary between the requesting thread and the key storage. The co-processor compares the current thread identifier with the thread owner field before allowing key access, serving as a security gate that prevents malicious software from intercepting and misusing keys while allowing legitimate cryptographic operations to proceed

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If thread ownership verification is implemented by comparing thread identifiers with stored key ownership information, then key security is enhanced, but additional processing steps are required during context switches

Engineering Contradiction:
Improvekey access securityVSAvoidcontext switch processing complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The thread owner field is pre-populated with the identifying information of the thread that owns each key during key provisioning. This preliminary action eliminates the need for complex verification logic during context switches, as the co-processor simply needs to compare the current thread identifier with the pre-stored thread owner field, maintaining security while minimizing additional processing complexity

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP3504837B1Thread ownership of keys for hardware-accelerated cryptography
Publication Date: 2024.04.17 TEXAS INSTRUMENTS INC
  • EP3504837B1 patent drawingFigure 1
  • EP3504837B1 patent drawingFigure 2
  • EP3504837B1 patent drawingFigure 3

AI summary

In described examples, an embedded processor with a cryptographic co-processor (15) operates in a multithreading environment, with inter-thread security for cryptography operations. A secure memory block (16) accessible by the co-processor (15) stores a plurality of key entries (25x), each key entry (25x) storing data corresponding to a cryptography key, and a thread owner field that identifies an execution thread is associated with that key. A central processing unit (12) issues a call to the co-processor (15) to execute a cryptography operation along with a key identifier for the key to be used, and a thread identifier indicating the current execution thread. The co-processor (15) compares the thread identifier received from the central processing unit (12) with the thread owner field of the key entry (25 x) corresponding to the key identifier. If the thread identifier matches the thread owner in the key entry (25x), the key is retrieved from the secure memory block (16) for use by the co-processor (15) for the cryptography operation.