Secure Boot Subsystem Halt Mechanism for Runtime Attack Prevention
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing secure boot procedures in computing systems are vulnerable to runtime attacks, as attackers can bypass verification processes by controlling other components of the system, potentially loading and executing malicious firmware, compromising the Chain of Trust and Root of Trust.
Innovation Solution
Implementing an open sub-system and a secure sub-system with a register accessible only by the secure sub-system, which can place the open sub-system into a halt state until verification is successfully completed, ensuring only verified firmware is executed, and using cryptographic algorithms for verification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a secure boot procedure is implemented with verification processes, then the security and reliability of the boot process is improved, but the device complexity and potential vulnerability to runtime attacks increases
Solution Approach 1:
The system is divided into two distinct sub-systems: a first sub-system that executes boot procedures and loads firmware, and a second sub-system that performs cryptographic verification of firmware. This segmentation isolates the verification function from the execution function, preventing runtime attacks where an attacker might compromise the boot procedure execution. The register mechanism further segments control, allowing the verification sub-system to halt the execution sub-system when unverified firmware is detected.
Solution Approach 2:
A register acts as an intermediary communication mechanism between the first and second sub-systems. The register is accessible only by the second sub-system and serves as a control signal carrier that can place the first sub-system into a halt state. This intermediary mechanism enables the verification sub-system to control the execution sub-system without direct architectural coupling, adding a layer of security while managing complexity.
2Reliability
If verification processes are performed during boot procedure, then the security against malicious firmware is improved, but the boot time and system initialization time increases
Solution Approach 1:
Cryptographic verification is performed in advance before the firmware is loaded into executable memory. The second sub-system verifies the firmware signature during the boot procedure before the first sub-system executes it. This preliminary verification action ensures that only verified firmware can be executed, and the verification timing is optimized to occur during the boot sequence rather than after firmware loading, minimizing overall boot time while maintaining security.
3Reliability
If a register accessible only by the secure sub-system is used to control the boot procedure, then the protection against runtime attacks is improved, but the device complexity and control mechanism complexity increases
Solution Approach 1:
The register is designed with selective accessibility - it is accessible only by the second sub-system (verification sub-system) and not by the first sub-system (execution sub-system) or external attackers. This local quality of restricted access creates a security boundary where the verification sub-system can control the boot procedure state without being exposed to runtime attacks. The register serves as a localized control mechanism that adds minimal complexity compared to the overall system architecture.
Data Source
AI summary
Protection for a secure boot procedure can be provided in addition to cryptographic verification of boot firmware associated with the boot procedure. While the boot firmware is being verified, an open sub-system can be placed into a halt state, during which the open sub-system is prevented from performing the boot procedure. The open sub-system can be subsequently placed into a resume state to further perform the boot procedure when the boot firmware is verified. The open sub-system is still prevented from performing the boot procedure even if the boot firmware is verified unless the open sub-system is placed into the resume state again.