Attesting Module Architecture for Secure Subsystem Booting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing secure boot technologies rely on the correctness of hardware, which is vulnerable to faults and compromises, leading to insecure attestation and inability to distinguish trust at the level of individual tiles, especially in complex and error-prone multi-core systems.
Innovation Solution
A module and architecture that allows for authenticated booting of subsystems by replicating attestation modules, enabling secure booting even with faulty components, and supporting relocation and relabeling of capabilities in a capability-based system, using a network-on-a-chip architecture with tamperproof storage and reconfigurable logic.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional secure boot technologies are used, then the boot process can be authenticated, but the system is vulnerable to hardware faults and compromises that undermine the root of trust
Solution Approach 1:
The system divides the boot authentication process into multiple independent stages involving separate attestation modules. Each attestation module independently verifies different aspects of the boot process, so that a fault or compromise in one module does not invalidate the entire authentication chain. This segmentation creates multiple roots of trust rather than relying on a single vulnerable root.
Solution Approach 2:
The patent introduces attestation modules as intermediary components between the hardware and the secure boot process. These modules act as mediators that verify the integrity of boot components and provide cryptographic attestation. The intermediaries isolate the system from direct hardware vulnerabilities by adding layers of verification that can detect and report faults without compromising the entire system.
2Measurement precision
If a single root of trust is used for authentication, then the boot process can be verified, but the system cannot distinguish trust at the level of individual tiles or components
Solution Approach 1:
The authentication architecture is segmented into multiple attestation modules, each responsible for specific tiles or components. This allows fine-grained trust verification where each module can independently attest to the integrity of particular hardware elements. The segmentation enables precise measurement of trust at component level rather than system-wide generic authentication.
Solution Approach 2:
Each attestation module is designed with specialized local capabilities to verify specific types of components or tiles. Rather than using a uniform authentication approach across the entire system, the patent applies local quality by tailoring each attestation module's verification scope and methods to its specific function, enabling precise local trust assessment.
3Adaptability or versatility
If the root of trust is fixed and unchangeable, then authentication can be consistent, but the system cannot adapt to updates or recover from compromises
Solution Approach 1:
The system implements dynamic root of trust through attestation modules that can be updated and reconfigured. Rather than fixed immutable authentication credentials, the patent employs dynamic credentials that can be rotated, updated, or regenerated. This allows the system to adapt to new security requirements or recover from compromises while maintaining authentication consistency through cryptographic verification of updates.
Solution Approach 2:
The patent enables discarding compromised attestation modules or credentials and recovering through replacement with new valid modules. The system can detect when a root of trust has been compromised and discard the affected credentials, then recover by installing new attestation modules with fresh cryptographic keys. This discarding and recovering mechanism maintains long-term reliability while enabling adaptability.
Data Source
Figure 1
Figure 2~3
Figure 4
AI summary
A capability-based data processing architecture (100) integrating an attesting module (120) are disclosed, together with subroutines for : securing the booting phase of a replicated or unreplicated subsystem (150) of computing units (130, 140) in the architecture and attesting to same; for adding and removing computing units (140) to and from booted systems 150; for relabelling authentication tokens when the booted subsystem (150) comprises computing units; for sealing and unsealing a memory storing data structures that are processed by the other subroutines described herein; and for recovering a booted subsystem (150) beset by faults.