Secure Boot Key Database Versioning for Driver and Bootloader Authentication
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Computer systems, especially appliances, face security vulnerabilities during the boot process due to the potential authentication of malicious software as legitimate code, even when using UEFI secure boot mechanisms, as standard industry public keys may inadvertently sign rogue software, and managing digital key certificates for all possible option components is infeasible.
Innovation Solution
Implementing a secure boot key database with different versions for various phases of the boot process, using a less restrictive version for authenticating standard industry drivers during the DXE phase and a more restrictive version for the operating system bootloader during the TSL phase, with the manufacturer acting as a higher-trust CA, and employing cryptographic hash functions to authenticate code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If standard industry public keys are used for authentication during boot, then ease of operation is improved, but security is worsened due to potential authentication of malicious software as legitimate code
Solution Approach 1:
The patent segments the authentication process into two distinct phases: DXE phase using a first key database with standard industry public keys for driver authentication, and TSL phase using a second key database with manufacturer-specific keys for bootloader authentication. This segmentation allows each phase to use appropriately restricted keys, improving security while maintaining ease of operation within each phase's context.
Solution Approach 2:
The patent applies local quality by using different authentication key databases for different phases of the boot process. The DXE phase uses a less restrictive key database suitable for driver authentication, while the TSL phase uses a more restrictive manufacturer-specific key database. This localized approach to authentication strength optimizes both security and ease of operation for each specific phase.
2Device complexity
If a single version of secure boot key database is used for all boot phases, then device complexity is reduced, but security is worsened due to inability to enforce higher trust for critical bootloader authentication
Solution Approach 1:
The patent divides the key database into two separate versions: a first version for the DXE phase containing standard industry public keys, and a second version for the TSL phase containing manufacturer-specific keys. This segmentation enables differentiated trust levels for different boot phases while keeping each individual key database relatively simple in structure.
Solution Approach 2:
The patent performs preliminary action by preparing both key database versions in advance and switching between them based on the boot phase. The firmware contains both key database versions and automatically selects the appropriate one, eliminating the need for complex runtime key management while maintaining high security standards.
3Adaptability or versatility
If multiple digital key certificates are stored for all possible option components, then adaptability is improved, but device complexity and security management become infeasible
Solution Approach 1:
The patent segments the key management scope by using the first key database version specifically for driver authentication during DXE phase, containing only the necessary standard industry public keys. This segmentation provides adaptability for driver compatibility while avoiding the infeasibility of managing certificates for all possible option components across the entire boot process.
Solution Approach 2:
The patent applies partial action by storing only the essential standard industry public keys in the first key database version, sufficient for driver authentication purposes. This partial key set provides adequate adaptability for driver compatibility without the excessive complexity of including all possible option component certificates.
Data Source
AI summary
A technique includes, in a first phase of a secure boot of a computer system, executing boot code of the computer system to access a first version of a secure boot key database to authenticate driver code. The first version of the secure boot key database stores a key corresponding to a plurality of drivers. The technique includes executing the boot code to automatically prepare the secure boot key database for a second phase of the secure boot in which operating system bootloader code is executed. Preparing for the second phase includes executing the boot code to automatically replace the first version of the secure boot key database with a second version of the secure boot key database, and the second version of the secure boot key database stores a key, which corresponds to the operating system bootloader code. The technique includes in the second phase of the secure boot, executing the boot code to access the secure boot key database to authenticate the operating system bootloader code.