Secure Processor Segmentation for TPM and Non-TPM Coexistence
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional secure processing systems, such as TPMs, face challenges in securely managing and protecting keys and data when non-TPM compliant applications are integrated, as they may compromise the security of TPM operations and expose sensitive information.
Innovation Solution
A secure processor is designed to support both TPM and non-TPM security functions, managing keys and performing cryptographic processes while maintaining the security boundary of the TPM, by using standard TPM commands and key structures for both TPM and non-TPM operations, ensuring that non-TPM operations do not affect or expose TPM data and keys.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a TPM is configured to support only TPM-compliant operations, then security and compliance are maintained, but functionality and adaptability are limited
Solution Approach 1:
The patent segments the secure processor into distinct functional areas: a TPM-compliant region that maintains strict security protocols and a non-TPM region that provides extended functionality. This segmentation allows non-TPM applications to access secure processing capabilities without compromising the integrity of TPM operations, as each region operates with appropriate security controls tailored to its specific requirements
Solution Approach 2:
The secure processor is designed with multi-functionality to support both TPM-compliant operations and non-TPM security functions within a single device. The processor can execute both standardized TPM commands and custom non-TPM commands, allowing it to serve diverse security needs while maintaining a unified security architecture under controlled conditions
2Adaptability or versatility
If additional non-TPM commands and resources are added to support non-TPM applications, then functionality is improved, but device complexity increases
Solution Approach 1:
The patent merges non-TPM security functions with the TPM architecture by implementing them within the same secure processor boundary. Non-TPM commands share cryptographic resources, key management infrastructure, and security enforcement mechanisms with TPM operations, reducing the need for separate hardware components and minimizing overall system complexity while maintaining functionality
3Adaptability or versatility
If non-TPM applications are integrated into the TPM, then adaptability is improved, but security risks increase due to potential exposure of TPM data and keys
Solution Approach 1:
The secure processor implements segmentation that isolates TPM data and keys from non-TPM applications through separate memory spaces, command validation layers, and access control mechanisms. This ensures that non-TPM operations cannot inadvertently or maliciously access TPM-protected information, maintaining security boundaries while enabling extended functionality
Solution Approach 2:
The patent introduces intermediary security mechanisms including command validation layers, authorized access controls, and isolated execution environments that mediate between non-TPM applications and the TPM core. These intermediaries enforce security policies, validate operations, and prevent unauthorized access to TPM resources, allowing safe integration of diverse applications
Data Source
AI summary
A secure processor such as a trusted platform module supports multiple security functions within a single secure processing environment. For example, the secure processor may be configured to perform functions in accordance with the TPM specification and to perform other, non-TPM, security functions. These security functions may be operated independently such that the operation of one security function does not violate or compromising the security of other security functions.