Trusted Booting by Hardware Root of Trust Device
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
There is a lack of confidence in the secure execution of commercial off-the-shelf (COTS) computers due to untrusted supply chains and inadequate monitoring of the boot process, which is critical for ensuring the integrity of native applications.
Innovation Solution
A method and system for secure booting that involves executing a first secure boot code, validating a security device, switching cores between secure and normal worlds, and monitoring the boot process using a security monitoring application, with authentication and decryption of boot loaders, and communication with a Trusted Platform Module (TPM) to ensure the integrity of the system.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a secure boot process is implemented with validation and monitoring, then system security and trust are improved, but device complexity and boot time increase
Solution Approach 1:
The boot process is divided into distinct stages: first-stage boot loader (FSBL) execution, security monitoring application validation, and second-stage boot loader (SSBL) execution. Each stage performs specific security functions independently, allowing complex security validation to be broken down into manageable segments that can be executed sequentially without overwhelming the system at once.
Solution Approach 2:
Security validation is performed in advance during the boot process before the full system operates. The security monitoring application validates the security device and verifies cryptographic signatures of boot loaders beforehand, ensuring that security checks are completed proactively rather than reactively, which builds trust before system execution begins.
2Productivity
If multiple cores are used for parallel processing, then productivity is improved, but security monitoring becomes more difficult
Solution Approach 1:
A security monitoring application acts as an intermediary between multiple processor cores and the security device. This intermediary monitors the state of all cores, manages secure world transitions, and coordinates validation activities, making it easier to track and control security across multiple parallel processing units without requiring direct monitoring of each core individually.
Solution Approach 2:
The system introduces a new dimension of execution environments by implementing separate secure world and normal world modes for processor cores. This dimensional separation allows productivity to be maintained in the normal world while security monitoring and validation occur in the isolated secure world, enabling parallel processing without compromising security observability.
3Reliability
If security validation is performed on boot loaders, then system integrity is improved, but boot time increases
Solution Approach 1:
Cryptographic signatures of boot loaders are verified in advance during the first-stage boot loader execution before the second-stage boot loader is loaded. This preliminary validation ensures system integrity is established early in the boot process, allowing subsequent stages to proceed without repeated validation delays.
Solution Approach 2:
Once security validation is successfully completed during the boot process, the system transitions quickly to normal operation, skipping repeated validation checks for subsequent operations. The security monitoring application caches validation results, allowing the system to rush through subsequent boot and operation phases without repeating time-consuming cryptographic verifications.
Data Source
AI summary
The concepts, systems and methods described herein are directed towards a method running on a security device. The method is provided to including: executing a first secure boot code from a first memory by one of a plurality of cores of a processor, wherein the plurality of cores runs in a secure world; executing a first-stage boot loader (FSBL) from a second memory; executing a security monitoring application to validate the security device; in response to the security device being validated, switching some of the plurality of cores from the secure world to a normal world, wherein at least one of the plurality of cores remains in the secure world to communicate with the security monitoring application; executing a second-stage boot loader (SSBL); and monitoring, via the security monitoring application, status of the security device and communications between the security device and at least one external system.