Firmware Update Locking for Boot Failure Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing firmware security mechanisms, such as password protection, are weak and vulnerable to attacks, leading to potential corruption and inoperability of electronic devices, with no secure method to update firmware in a non-functional state without relying on potentially compromised firmware.
Innovation Solution
A hardware-based lock mechanism secures firmware storage and enables exclusive access for agents to update firmware directly, using a mutually exclusive locking scheme to prevent unauthorized access and ensure secure firmware updates even in the absence of valid firmware.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If password protection is used to prevent unauthorized access to firmware, then firmware security is improved to some level, but the protection is weak and can be compromised by external attackers
Solution Approach 1:
The patent replaces software-based password protection with a hardware-based lock mechanism. The lock unit is implemented in hardware logic that physically prevents access to the firmware storage resource when locked, rather than relying on software authentication that can be compromised. This substitution of hardware enforcement for software protection eliminates the vulnerability to external attacks that can compromise password-based systems.
Solution Approach 2:
The patent segments the access control function from the firmware storage resource by introducing a separate lock unit. The lock unit independently controls access to the resource through hardware-enforced locking and unlocking operations, creating a distinct security layer that operates separately from the firmware itself. This segmentation allows the security mechanism to be hardened independently from the protected resource.
2Adaptability or versatility
If firmware is stored in nonvolatile memory accessible by multiple agents, then firmware can be updated and managed, but the firmware may be corrupted or accessed unauthorizedly during updates
Solution Approach 1:
The patent applies preliminary anti-action by establishing a locked state on the firmware resource before any update operation begins. The lock unit prevents any agent from accessing or modifying the firmware during critical operations. By preemptively blocking access through hardware locking, the system prevents potential corruption or unauthorized modifications before they can occur, ensuring firmware integrity while still allowing controlled updates through proper unlocking procedures.
3Ease of repair
If sideband firmware is used to repair corrupted firmware, then device recovery is enabled, but the sideband firmware itself can be compromised by attackers
Solution Approach 1:
The patent replaces the vulnerable sideband firmware mechanism with a hardware-based lock unit that directly controls access to the firmware resource. Instead of relying on another layer of firmware (sideband) to repair corrupted firmware, the hardware lock unit provides direct, secure control over access permissions. This eliminates the security vulnerability inherent in using firmware-based repair mechanisms while maintaining the ability to recover devices through controlled unlocking and updating operations.
Data Source
AI summary
A new approach is proposed to support hardware-based update of a software (e.g., a firmware) of an electronic device in a non-functional state. Under the proposed approach, the software is stored securely on a resource (e.g., a non-volatile storge) protected by a hardware-based lock mechanism. A first agent acquires a lock and authenticate the software. When a boot failure (e.g. authentication of the software fails) of the electronic device happens, an alert indicating the failure is generated and sent to a second agent (e.g., a sideband master) through an alert mechanism. The second agent then acquires a lock from the hardware-based lock mechanism to obtain exclusive excess to the resource and update the software stored in the non-volatile storage through, e.g., block write and/or read operations. The second agent then verifies that the software has been updated successfully so that the electronic device becomes functionally again.