Automotive Controller Malware Prevention via Kernel Whitelisting
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Internet of Things (IoT) devices, such as automotive Electronic Control Units (ECUs), are vulnerable to cyber attacks due to security bugs like buffer overflows, allowing hackers to gain control and execute malware, posing risks to vehicle functions and safety.
Innovation Solution
Implementing customized security policies automatically generated for controllers, which include a whitelist enforcement, network firewall, and port protection agent, to restrict operations and behaviors, preventing unauthorized code execution and blocking malware attempts at the entry point, thus securing the IoT device's infrastructure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If internet-connected controllers are made more versatile and connected, then functionality and communication capability are improved, but vulnerability to cyber attacks increases
Solution Approach 1:
The patent segments the controller into multiple protected domains with isolation mechanisms. Each domain can be independently secured, and the segmentation creates boundaries that prevent lateral movement of malware between different controller functions, thus maintaining communication versatility while reducing overall vulnerability.
Solution Approach 2:
The patent introduces security layers and intermediary components between external communication interfaces and internal controller systems. These intermediaries act as buffers that inspect, filter, and monitor traffic, allowing the controller to maintain internet connectivity while preventing direct access to vulnerable internal systems.
2Reliability
If security layers and policies are added to controllers, then malware prevention is improved, but device complexity increases
Solution Approach 1:
The patent implements preliminary security measures during the software development phase, including static analysis of code for vulnerabilities, creation of security policies before deployment, and pre-configured isolation domains. By performing these actions beforehand, the system achieves strong malware prevention without adding runtime complexity or requiring complex security infrastructure during operation.
Solution Approach 2:
The patent enables the controller to automatically enforce security policies and monitor its own operations without external intervention. The system self-audits code execution, automatically blocks malicious activities, and maintains security domains autonomously, reducing the need for complex external security management systems.
3Object-affected harmful factors
If input buffer verification is implemented, then security against buffer overflow attacks is improved, but processing time increases
Solution Approach 1:
The patent performs buffer size verification and input validation during the compilation and software development phases rather than during runtime execution. Security policies are pre-established and embedded in the controller, allowing rapid validation without adding significant processing delay during actual operation.
Solution Approach 2:
The patent replaces complex runtime buffer checking mechanisms with lighter-weight verification approaches, such as compiler-enforced type checking, static analysis, and policy-based access control. These substitutions maintain security against buffer overflow attacks while significantly reducing the computational overhead and processing time associated with runtime validation.
Data Source
AI summary
In one implementation, a method for providing security on an externally connected controller includes launching, by the controller, a kernel level security layer that includes a whitelist of permitted processes on the controller, the whitelist being part of a custom security policy for the controller; receiving, at the security layer, a request to run a particular process; determining, by the security layer, a signature for the particular process; identifying, by the security layer, a verified signature for the process from the whitelist; determining, by the security layer, whether the particular process is permitted to be run on the controller based on a comparison of the determined signature with the verified signature from the whitelist; and blocking, by the security layer, the particular process from running on the automotive controller based on the determined signature not matching the verified signature for the process.