In-Vehicle Software Authorization Using Local SBOM Updates
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing software management systems fail to dynamically manage software installed in vehicles based on user contracts, leading to potential vulnerabilities and inefficiencies due to discrepancies between centrally stored software information and actual user usage.
Innovation Solution
An information processing method and device that manage software operability in vehicles by detecting new additions, determining user contracts, and updating software information lists to reflect actual user permissions, using a local software bill of materials (SBOM) to ensure software is only activated for contracted functions, thereby addressing vulnerabilities and improving responsiveness.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Device complexity
If software information is centrally stored on a server, then software management is simplified, but the system cannot detect new software additions and update information in real-time, leading to security vulnerabilities
Solution Approach 1:
The patent divides the software information management system into two segments: a central server for storing baseline software information and a local in-vehicle system for detecting new software additions and maintaining an updated software bill of materials (SBOM). This segmentation allows the server to provide centralized management while the local system ensures real-time security updates by detecting new software independently.
Solution Approach 2:
The patent implements preliminary action by having the in-vehicle system continuously monitor and detect new software additions before they can pose security risks. The system proactively compares detected software against the centralized SBOM and prepares update information in advance, ensuring security vulnerabilities are addressed before exploitation can occur.
2Adaptability or versatility
If all software is activated by default, then system functionality is maximized, but users cannot control which functions are operable based on their contracts
Solution Approach 1:
The patent implements dynamic software activation by continuously monitoring user contracts and automatically enabling or disabling software functions based on current contract status. The system dynamically adjusts which software is operable rather than using static default activation, allowing users to control functionality through their contracts while maintaining system versatility.
Solution Approach 2:
The patent establishes a feedback mechanism where the system continuously monitors both software usage and contract status, then automatically adjusts software activation accordingly. This closed-loop feedback ensures that only contracted functions remain operable, giving users control over system functionality through their contractual agreements.
3Reliability
If software updates are performed frequently, then security vulnerabilities are addressed promptly, but system stability may be compromised and update management becomes complex
Solution Approach 1:
The patent extracts the complexity of frequent software update management from the in-vehicle system by implementing a centralized server that handles update distribution. The in-vehicle system only needs to detect new software, compare it against the centralized SBOM, and apply updates when authorized, significantly reducing update management complexity while maintaining security.
Solution Approach 2:
The patent implements preliminary action by maintaining a pre-approved SBOM at the server containing verified safe software versions. Before applying updates, the system checks against this pre-validated list, ensuring that only security-critical updates are applied while maintaining system stability and simplifying update management through advance verification.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An information processing method executed using a computer in a vehicle 100 that switches whether or not each of equipped functions is to be made operable, depending on whether or not a user of the vehicle 100 has a contract for the function. The information processing method includes: a detection step S11 of detecting a new addition of software for operating one or more functions; a determination step S14 of determining whether or not the user has a contract for the function operated by the software, the new addition of which has been detected; an acquisition step of acquiring software information corresponding to the software for which it is determined that the user has a contract; and update steps (step S15, step S16, and step S17) of updating a software information list of functions operable in the vehicle by adding the acquired software information.