BMC Secure Boot With Hidden Root Key Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current secure boot environments in information handling systems prevent customers from installing and booting their own firmware while maintaining security, as they restrict customers from flashing their own firmware and running it on unauthorized BMCs, and do not allow for a secure handoff between manufacturer and customer firmware.
Innovation Solution
A baseboard management controller (BMC) with a unique hidden root key (HRK) and non-volatile storage, which includes customer and manufacturer firmware partitions, performs double verification using symmetric and asymmetric signature verification to ensure only authorized firmware is executed, preventing overwriting of manufacturer code and allowing customers to securely boot their own firmware.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If secure boot environment restricts customers from flashing their own firmware, then security is maintained, but customer ability to install and boot their own firmware is prevented
Solution Approach 1:
The non-volatile storage is segmented into multiple partitions: BMC partitions (containing manufacturer firmware) and customer firmware partition. This segmentation allows customer firmware to be stored and executed separately from manufacturer firmware, enabling customer firmware installation while maintaining secure boot integrity through partition-level security controls.
Solution Approach 2:
A dual verification mechanism acts as an intermediary between customer firmware and the secure boot environment. The BMC firmware verifies both a manufacturer signature and an HRK hash before allowing customer firmware to execute, providing a secure handoff that maintains trust while enabling customer firmware execution.
2Adaptability or versatility
If customers are allowed to boot their own firmware, then firmware flexibility is improved, but risk of executing unauthorized or malicious code increases
Solution Approach 1:
The system performs preliminary verification actions before executing customer firmware. The BMC firmware verifies the manufacturer signature and HRK hash in advance, ensuring that only authorized and intact firmware is executed. This preliminary verification prevents malicious code execution while maintaining firmware flexibility.
Solution Approach 2:
The verification mechanism provides feedback control by checking the manufacturer signature and HRK hash before allowing firmware execution. If verification fails, the system prevents execution; if verification succeeds, the system allows execution. This feedback loop ensures security while enabling flexible firmware execution.
3Reliability
If manufacturer firmware is protected from overwriting, then secure boot integrity is maintained, but customer ability to update or modify firmware is restricted
Solution Approach 1:
The storage is segmented into read-only BMC partitions containing manufacturer firmware and a separate customer firmware partition. This segmentation protects manufacturer firmware from overwriting while allowing customer firmware to be updated independently, maintaining both integrity and update capability.
Solution Approach 2:
Different security properties are applied to different partitions: BMC partitions are protected from overwriting to maintain manufacturer firmware integrity, while the customer firmware partition allows updates. This local differentiation of security properties enables both protection and flexibility.
4Reliability
If a unique hidden root key is used for verification, then firmware authorization is strengthened, but complexity of verification process increases
Solution Approach 1:
The verification process merges two verification elements (manufacturer signature and HRK hash) into a single unified check performed by the BMC firmware. This combining of verification steps strengthens authorization security while managing complexity through integrated verification logic.
Data Source
AI summary
In one or more embodiments, one or more systems, methods, and/or process may allow a customer to install and boot their own firmware securely, without compromising secure boot. A baseboard management controller (BMC) may include a BMC firmware stored via a BMC partition of a non-volatile storage, a customer firmware image including a customer firmware and a signed customer boot block (CBB) file including a CBB, a hidden root key (HRK) hash of the CBB based on a HRK, and a manufacturer signature. The BMC firmware may, when an alternate path to boot the CBB is detected, verify the manufacturer signature on the CBB and the HRK hash, verify the HRK hash based on the unique HRK, and when the manufacturer signature and the HRK hash have been verified, hardware lock the BMC partition, disable the HRK, and transfer control to the CBB.