Countersigning Multi-Chip Software Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multi-chip electronic devices, security vulnerabilities in secondary chips can compromise the entire device's security, despite strong security measures implemented by primary chips, due to uncontrolled software updates.
Innovation Solution
A system where a primary entity countersigns software updates for secondary chips, ensuring they do not compromise device security by verifying updates using a manifest data item signed with a private key, and preconfiguring secondary chips with public and symmetric keys to verify authenticity.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If software updates are allowed for secondary chips, then functionality and security patches are improved, but security vulnerabilities may be introduced through uncontrolled updates
Solution Approach 1:
The patent introduces a manifest file as an intermediary component that mediates between the update package and the secondary chip. The manifest contains authentication data (digital signature, hash values) that verifies the authenticity and integrity of updates before they are installed, acting as a trusted intermediary that prevents unauthorized or malicious updates from compromising security.
Solution Approach 2:
The patent implements preliminary verification actions through multiple checks before update installation: (1) verifying the manifest's digital signature against the primary chip's public key, (2) checking hash values of update components against manifest data, and (3) validating authentication codes. These preliminary actions ensure that only authenticated and intact updates are installed, preventing security vulnerabilities before they can occur.
2Reliability
If update verification mechanisms are implemented, then security control is improved, but system complexity increases due to multiple key verifications
Solution Approach 1:
The patent segments the verification system into distinct, modular components: (1) manifest verification module that checks digital signatures, (2) hash verification module that validates data integrity, and (3) authentication code verification module that confirms update legitimacy. This segmentation allows each verification function to be implemented independently, making the complex verification process more manageable and maintainable.
Solution Approach 2:
The manifest file serves as an intermediary data structure that organizes and presents verification information in a standardized format. It contains all necessary authentication data (signatures, hashes, authentication codes) in a structured manner, simplifying the verification process by providing a single point of reference rather than requiring direct complex interactions between multiple verification components.
3Reliability
If multiple authentication mechanisms are used, then update authenticity is improved, but processing time increases due to multiple verification steps
Solution Approach 1:
The patent performs preliminary organization of authentication data in the manifest file during update package creation. All verification所需的 data (digital signatures, hash values, authentication codes) are pre-calculated and embedded in the manifest, allowing the receiving system to perform verification operations efficiently without needing to perform complex calculations during the actual update installation process.
Solution Approach 2:
The patent replaces complex mechanical verification processes with cryptographic mathematical operations. Instead of using cumbersome physical or procedural verification methods, the system uses digital signatures based on public-key cryptography and hash-based authentication codes, which can be verified rapidly through mathematical computations, significantly reducing verification time while maintaining high security.
Data Source
AI summary
A device facilitating countersigning updates for multi-chip devices includes at least one processor configured to receive, from a collocated chip, a data item and a software update, the data item being signed using a private key corresponding to a primary entity associated with the collocated chip and the data item comprising an authentication code generated using a symmetric key corresponding to a secondary entity associated with the software update. At least one processor is further configured to verify the data item using a public key associated with the primary entity. At least one processor is further configured to verify the software update based at least in part on the authentication code and using the symmetric key corresponding to the primary entity. At least one processor is further configured to install the software update when both the data item and the software update are verified, otherwise discard the software update.