Hash-Based Root of Trust Binding for DC-SCM and HPM Mobility

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing server architectures lack robust mechanisms to establish and reestablish trust between modular components, leading to potential unauthorized access and configuration issues when the Datacenter-Secure Control Module (DC-SCM) is moved between systems.

Innovation Solution

Implement a system-level Root of Trust (RoT) binding process using a baseboard management controller (BMC) to calculate and verify hash values from hardware identity certificates and firmware measurements, ensuring secure binding and recovery actions based on user-configured policies.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If the DC-SCM is moved between different HPM systems to improve resource utilization and flexibility, then adaptability is improved, but system security and trust establishment deteriorate due to lack of binding verification

Engineering Contradiction:
ImproveDC-SCM mobility between systemsVSAvoidtrust establishment
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent performs preliminary binding verification during system initialization by calculating hash values from hardware identity certificates and firmware measurements, and storing these binding relationships before the DC-SCM is moved or reused. This preliminary action ensures that when the DC-SCM is later moved between systems, the pre-established binding verification can quickly determine whether the movement is authorized, thus maintaining security while enabling flexibility.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements a feedback mechanism where the BMC continuously verifies the binding relationship between DC-SCM and HPM by comparing current hash values with stored binding information. This feedback loop provides real-time security verification, allowing the system to detect unauthorized movements and trigger appropriate responses, thereby maintaining reliability while permitting legitimate adaptability.

Inventive Principle:
Principle #23Feedback

2Reliability

If hash value verification is performed on all SPDM-capable hardware devices to ensure security, then system security is improved, but device complexity and processing overhead increase

Engineering Contradiction:
Improvesystem securityVSAvoidbinding verification complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent segments the security verification process by device type, applying different verification strategies to different SPDM-capable hardware devices. Instead of uniformly verifying all devices with the same complex process, the system identifies and verifies critical devices (such as processors, memory controllers, and I/O devices) with full hash value verification, while using simplified verification for less critical devices. This segmentation maintains high security for critical components while reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements partial verification by focusing hash value verification on the most critical hardware components that form the root of trust chain. Rather than verifying every single hardware device in the system with equal depth, the system performs exhaustive verification on critical path devices while using lighter verification methods for non-critical devices, achieving adequate security with reduced processing overhead.

Inventive Principle:
Principle #16Partial or excessive action

3Reliability

If recovery actions are implemented when binding verification fails to prevent unauthorized access, then security is improved, but system availability and ease of operation deteriorate due to boot prevention

Engineering Contradiction:
Improveunauthorized access preventionVSAvoidsystem booting
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements dynamic recovery actions that adapt based on the specific verification failure scenario and system configuration. Rather than uniformly preventing boot for all verification failures, the system evaluates the nature of the failure and applies appropriate responses: for minor failures, it may allow boot with warnings; for critical failures, it prevents boot and triggers recovery procedures. This dynamic approach balances security with operational flexibility, allowing legitimate operations to proceed while blocking unauthorized access.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes security parameters dynamically based on verification results and configured policies. When binding verification fails, the system adjusts security parameters such as boot authorization, license validation, and configuration access based on user-configured security policies. This allows the same verification failure to result in different outcomes depending on the configured risk tolerance and operational requirements, balancing security enforcement with operational continuity.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12373562B2System level root of trust (ROT) binding and trust establishment
Publication Date: 2025.07.29 DELL PROD LP
  • US12373562B2 patent drawing
  • US12373562B2 patent drawing
  • US12373562B2 patent drawing

AI summary

Systems and methods provide an Information Handling System (IHS), comprising a host processor module and a secure control module. A baseboard management controller executes a process that binds the host processor module to the secure control module using a hash value calculated from characteristics of components of the first host processor module. The process to bind the first host processor module to the secure control module comprises retrieving hardware identity certificates from all SPDM-capable hardware devices in the first host processor module, retrieving firmware measurements from all SPDM-capable hardware devices in the first host processor module, calculating an initial hash value from the hardware identity certificates and the firmware measurements, and storing the initial hash value either in the baseboard management controller or in the security processor.