Trusted Code Execution via Hidden Root Key

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current information handling systems face challenges in ensuring secure authentication and protection of data stored on storage devices, particularly in preventing unauthorized access and ensuring secure booting processes.

Innovation Solution

The system employs asymmetric encryption using a public/private key pair for digital signatures, combined with protected storage and a microprocessor that generates a hidden root key by combining a fused random value and public key, enabling secure access to protected storage while preventing unauthorized booting and data access.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If asymmetric encryption with public/private key pair is used for digital signatures, then secure authentication and data protection are improved, but device complexity increases due to key management and cryptographic operations

Engineering Contradiction:

Improvesecure authenticationVSAvoidkey management complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The microprocessor automatically generates the hidden root key by combining the fused random value and public key during initialization, eliminating the need for external key generation or manual configuration. This self-service approach reduces deployment complexity while maintaining cryptographic security.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The hidden root key acts as an intermediary that bridges the public key infrastructure and the protected storage access control. Instead of directly managing complex public/private key pairs for storage access, the system uses this derived hidden root key as a simplified authentication credential.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Reliability

If a hidden root key is generated by combining fused random value and public key, then secure access to protected storage is improved, but manufacturing precision requirements increase due to fused random value integration

Engineering Contradiction:

Improveprotected storage access securityVSAvoidfused random value integration

Core Design Contradiction:

ReliabilityVSManufacturing precision

Solution Approach 1:

The fused random value is generated and embedded in the microprocessor during manufacturing, before the device is deployed. This preliminary action ensures that the cryptographic foundation is established with high entropy and uniqueness at the hardware level, eliminating the need for complex runtime random generation.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The system combines two distinct elements—the manufactured fused random value and the cryptographic public key—into a single hidden root key. This merging approach leverages both hardware-based entropy and cryptographic strength to create a robust authentication credential.

Inventive Principle:

Principle #5Merging (Combining)

3Reliability

If protected storage is used to store authentication credentials, then data security is improved, but access control complexity increases due to credential verification processes

Engineering Contradiction:

Improvedata securityVSAvoidcredential verification complexity

Core Design Contradiction:

ReliabilityVSDevice complexity

Solution Approach 1:

The authentication credentials (hidden root key) are extracted and stored in a dedicated protected storage region with restricted access. This separation isolates sensitive credentials from the rest of the system memory, reducing the attack surface and simplifying security model by creating a clear trust boundary.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The storage system is segmented into protected and unprotected regions, with the hidden root key and authentication credentials confined to the protected segment. This segmentation allows simplified access control logic where trusted code automatically has access to protected storage, while untrusted code is explicitly blocked.

Inventive Principle:

Principle #1Segmentation

4Adaptability or versatility

If trusted code is allowed to execute arbitrary code, then system versatility is improved, but security risks increase due to potential unauthorized code execution

Engineering Contradiction:

Improvecode execution flexibilityVSAvoidunauthorized code execution risk

Core Design Contradiction:

Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The system implements dynamic code execution environments where trusted code can execute arbitrary code when needed, but only within the context of authenticated sessions. The execution privileges are dynamically granted and revoked based on authentication state, allowing versatility when trusted while preventing unauthorized execution.

Inventive Principle:

Principle #15Dynamics

Solution Approach 2:

The hidden root key and protected storage authentication mechanism serve as an intermediary layer between untrusted external code and the trusted code execution environment. This intermediary verifies authentication credentials before allowing any code to access protected resources or execute with elevated privileges.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS9684789B2Arbitrary code execution and restricted protected storage access to trusted code

Publication Date: 2017.06.20 AVENTAIL A WHOLLY OWNED SUBSIDIARY OF SONICWALL

AI summary

A method comprises signing boot code with a public/private cryptographic key pair, and writing to storage the boot code, the public cryptographic key, and the signed boot code.