TPM 2.0 Platform Hierarchy for UEFI Variable Security

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Despite advanced boot protocols like UEFI Secure Boot and secure cryptoprocessors, malware remains a threat to trusted computing due to vulnerabilities in BIOS software and TPMs, particularly in UEFI variables which can be susceptible to malicious attacks and lack confidentiality control.

Innovation Solution

The implementation of TPM 2.0's platform hierarchy allows firmware to access and manipulate UEFI variables securely during runtime, enabling secure enable/disable of secure enclaves, preventing roll-back attacks, and toggling between OSes by cryptographically binding variables to the TPM, providing strong access controls and integrity protection.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If UEFI variables are stored in flash memory without cryptographic binding, then ease of operation is improved, but security is worsened due to susceptibility to malicious attacks

Engineering Contradiction:
ImproveVariable access simplicityVSAvoidSecurity against malware
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The TPM acts as an intermediary between the UEFI variables and the system, providing cryptographic binding and access control. The TPM stores authenticated versions of variables and verifies signatures before allowing access, mediating between the simple flash storage and the security requirements without complicating the operational interface.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent replaces the mechanical/trust-based security model with cryptographic mechanisms. Instead of relying on physical security or trust in the firmware, the system uses digital signatures, hash functions, and cryptographic verification to protect UEFI variables, substituting cryptographic proof for traditional security mechanisms.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

2Adaptability or versatility

If firmware can freely access and manipulate UEFI variables during runtime, then adaptability is improved, but security is worsened due to lack of access controls

Engineering Contradiction:
ImproveRuntime variable manipulationVSAvoidAccess control security
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system implements dynamic access control where the TPM evaluates authentication criteria at runtime and selectively grants access to UEFI variables. The authentication policies are flexible and can adapt to different contexts, allowing legitimate firmware to access variables while blocking unauthorized access, thus providing both adaptability and security.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The TPM serves as a mediator that sits between firmware and UEFI variables, implementing access control policies. When firmware needs to access or manipulate variables, the TPM verifies authentication criteria and either permits or denies the operation, providing controlled adaptability without compromising security.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Device complexity

If UEFI variables lack cryptographic authentication, then device complexity is reduced, but integrity protection is worsened making systems vulnerable to roll-back attacks

Engineering Contradiction:
ImproveVariable storage simplicityVSAvoidIntegrity protection
Core Design Contradiction:
Device complexityVSReliability

Solution Approach 1:

The system creates authenticated copies of UEFI variables stored in the TPM. The original variables remain in flash memory for simplicity, while the TPM maintains cryptographically signed versions that serve as authenticated copies. This allows the system to maintain simple storage while having verified copies for security-critical operations.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent substitutes cryptographic authentication mechanisms for simple storage. Instead of relying solely on the physical integrity of flash memory, the system uses digital signatures and hash-based message authentication codes (HMAC) to verify variable integrity, replacing physical security assumptions with cryptographic proof.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

4Productivity

If multiple entities can access the TPM simultaneously, then productivity is improved, but security is worsened due to potential conflicts and unauthorized access

Engineering Contradiction:
ImproveConcurrent access efficiencyVSAvoidAccess control security
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system implements dynamic access control policies that are evaluated at runtime based on the specific authentication criteria. The TPM can handle multiple concurrent access requests by evaluating different authentication policies for different entities, dynamically granting or denying access based on real-time verification rather than static permissions.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The TPM implements feedback mechanisms where authentication criteria are evaluated and access decisions are made based on verified credentials. The system provides feedback to requesting entities about whether access is granted or denied, and maintains audit trails of access attempts, enabling secure concurrent access through continuous verification and monitoring.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP3161716B1Management of authenticated variables
Publication Date: 2023.08.30 INTEL CORP
  • EP3161716B1 patent drawingFigure 1
  • EP3161716B1 patent drawingFigure 2
  • EP3161716B1 patent drawingFigure 3

AI summary

An embodiment includes an apparatus comprising: an out-of-band cryptoprocessor coupled to secure non-volatile storage; and at least one storage medium having firmware instructions stored thereon for causing, during runtime and after an operating system for the apparatus has booted, the cryptoprocessor to (a) store a key within the secure non-volatile storage, (b) sign an object with the key, while the key is within the cryptoprocessor, to produce a signature, and (c) verify the signature. Other embodiments are described herein.