Secure Asset Management Unit for Privilege Violation Protection

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current computing systems, particularly personal computers, face challenges in maintaining the confidentiality and integrity of sensitive code and data due to vulnerabilities in software-based security solutions, which are susceptible to reverse engineering and tampering, especially when implementing digital rights management (DRM) systems.

Innovation Solution

A hardware-based secure execution environment is provided through a Secure Asset Management Unit (SAMU) that offloads sensitive code and data for encryption and authentication, offering a tamper-resistant platform with on-demand loading and run-time protection, managing memory contexts to ensure confidentiality and preventing privilege violations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If software-based security solutions are used to protect sensitive code and data, then implementation flexibility is improved, but security reliability deteriorates due to susceptibility to reverse engineering and tampering

Engineering Contradiction:

Improveimplementation flexibilityVSAvoidsecurity reliability

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The system segments security functionality into a separate secure execution environment (secure enclave) isolated from the main processor. This creates a distinct protected region where sensitive code and data can execute with enhanced security guarantees, while the rest of the system maintains its flexibility. The segmentation allows software-based solutions to benefit from hardware-enforced isolation.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

A hardware-based secure execution environment acts as an intermediary between the untrusted external environment and sensitive internal resources. This intermediary provides a trusted boundary that enables software security mechanisms to operate within a hardened context, combining the flexibility of software with the reliability of hardware enforcement.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Ease of operation

If credential-based security systems are implemented to restrict register access, then access control is improved, but security robustness deteriorates due to credential theft and single-policy limitations

Engineering Contradiction:

Improveaccess controlVSAvoidsecurity robustness

Core Design Contradiction:

Ease of operationVSReliability

Solution Approach 1:

The system implements dynamic access control policies that can change at runtime based on context, moving beyond static credential verification. Access decisions are made dynamically based on multiple factors including data sensitivity, execution context, and security policies, making the system more robust against credential theft while maintaining ease of operation.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

Different security policies are applied to different data and code regions based on their sensitivity requirements. Critical assets receive stronger protection measures while less sensitive resources maintain easier access, creating a nuanced security model that enhances overall robustness without uniformly complicating access control.

Inventive Principle:

Principle #3Local quality

3Reliability

If load-time authentication is used to verify software code, then initial security is improved, but run-time protection deteriorates leaving systems susceptible to programming attacks and data corruption

Engineering Contradiction:

Improveinitial securityVSAvoidprotection duration

Core Design Contradiction:

ReliabilityVSDuration of action of moving object

Solution Approach 1:

Security verification and protection mechanisms operate continuously throughout the execution lifecycle, not just at load time. The secure execution environment maintains ongoing integrity checks and protection measures, ensuring that security coverage extends from initial loading through entire runtime execution, preventing attacks that occur after initial authentication.

Inventive Principle:

Principle #20Continuity of useful action

4Reliability

If hardware-based secure execution environments are implemented, then security reliability is improved, but device complexity increases

Engineering Contradiction:

Improvesecurity reliabilityVSAvoidarchitecture complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The secure execution environment is designed to provide multiple security functions within a single hardware structure. It simultaneously offers isolated execution, memory protection, key management, and authentication capabilities, reducing overall system complexity compared to implementing separate dedicated hardware for each security function while maintaining high reliability.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentEP2630607B1Method and apparatus including architecture for protecting sensitive code and data

Publication Date: 2016.11.30 ADVANCED MICRO DEVICES INC

Figure 1A
Figure 1B
Figure 2

AI summary

A secure execution environment for execution of sensitive code and data including a secure asset management unit (SAMU) is described. The SAMU provides a secure execution environment to run sensitive code, for example, code associated with copy protection schemes established for content consumption. The SAMU architecture allows for hardware-based secure boot and memory protection and provides on-demand code execution for code provided by a host processor. The SAMU may boot from an encrypted and signed kernel code, and execute encrypted, signed code. The hardware-based security configuration facilitates preventing vertical or horizontal privilege violations.