Secure Boot Chain Using Shared Secrets for Faster Firmware Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing electronic devices, particularly those without hardware accelerators like eMMC and UFS, face challenges in performing secure booting operations quickly due to the time-consuming nature of public key-based digital signature verification.
Innovation Solution
A secure booting system utilizing a shared host pre-installed secret (HPS) value for generating booting values through hash-based operations, allowing for symmetric-key based secure booting without the need for hardware accelerators.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If public key-based digital signature verification is used for secure booting, then security and integrity verification are ensured, but booting speed becomes slow
Solution Approach 1:
The secure booting process is segmented into multiple stages with different verification mechanisms. Stage 1 uses symmetric key verification for fast booting, while Stage 2 uses public key verification for enhanced security. This segmentation allows the system to balance speed and security by applying appropriate verification methods at different booting stages.
Solution Approach 2:
Public key verification is performed in advance during device initialization or firmware update, and the verification results are cached. During actual booting, the cached results are used to speed up the process, eliminating the need for repeated computationally intensive public key operations.
2Speed
If hardware accelerator is added to speed up secure booting, then booting speed improves, but device cost and complexity increase
Solution Approach 1:
The patent uses software-based cryptographic algorithms that replicate the functionality of hardware accelerators through efficient software implementation. By optimizing the software cryptographic library and using lookup tables for common operations, the system achieves hardware-like performance without adding physical hardware components.
Solution Approach 2:
The system dynamically adjusts verification parameters such as hash algorithm selection and verification depth based on device capabilities and security requirements. This allows the same device to operate in different performance modes, achieving fast booting on resource-constrained devices without requiring hardware accelerators.
3Reliability
If public key verification is performed for each boot loader and firmware, then security is maintained, but processing time increases significantly
Solution Approach 1:
The verification process is segmented into critical path and non-critical path operations. Only essential verification steps are performed during booting, while secondary verifications are deferred or performed asynchronously, reducing the time impact on the booting process.
Solution Approach 2:
The system performs partial verification by checking only critical components first (such as boot loader signature) and skipping verification of less critical components if time constraints are met. This partial action approach ensures security for essential elements while accepting reduced verification coverage to maintain fast booting.
Data Source
AI summary
An electronic device includes at least one processor, a first storage unit configured to store a secret value set by a host, a second storage unit configured to store a boot loader code, a first firmware code, and a second firmware code, and a read-only memory (ROM) configured to store a ROM code executable in a booting operation. The ROM code, when executed, may cause the at least one processor to generate a first booting value based on the secret value and a first hash value for the boot loader code, the boot loader code, when executed, may cause the at least one processor to generate a second booting value based on the first booting value and a second hash value for the first firmware code, and the first firmware code, when executed, may cause the at least one processor to generate a third booting value based on the second booting value and a third hash value for the second firmware code.


