Multi-Level Whitelist Architecture for Secure Code Execution
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current methods for protecting computer systems from unauthorized code execution, such as malware and unlicensed software, are ineffective due to reliance on signature-based approaches that fail against variations and lack proactive enforcement mechanisms.
Innovation Solution
A multi-level whitelist architecture intercepts code module requests and uses a combination of MRU caches, local, and global whitelists, along with cryptographic hash values, to authenticate and authorize code execution, ensuring only authorized code is executed and enforcing license constraints.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If signature-based approaches are used for malware detection, then known malware can be detected, but variations and new malware cannot be effectively detected
Solution Approach 1:
Instead of maintaining a blacklist of known malware signatures, the patent inverts the approach by implementing a whitelist system that only permits execution of authorized and verified code modules. This fundamental inversion resolves the contradiction by making the system inherently adaptive to new malware variations while maintaining precision through cryptographic verification of allowed code.
Solution Approach 2:
The patent applies preliminary action by pre-associating cryptographic hash values with authorized code modules before execution. This pre-verification mechanism ensures that only pre-approved code can execute, automatically adapting to new threats without requiring signature updates, thus resolving both detection precision and adaptability requirements.
2Reliability
If real-time background monitoring is implemented, then malware execution can be detected, but the system consumes significant resources and may miss variations
Solution Approach 1:
The patent performs the verification action preliminarily by checking cryptographic hash values against the whitelist before code execution is permitted. This pre-check mechanism ensures reliable malware detection without requiring continuous resource-intensive monitoring during runtime, as the authorization decision is made once before execution begins.
Solution Approach 2:
The patent introduces an intermediary verification mechanism using cryptographic hash values as mediators between the code module and the execution environment. This intermediary approach provides reliable verification through mathematical proof of authorization while consuming minimal system resources, eliminating the need for continuous monitoring.
3Reliability
If a whitelist architecture is implemented, then only authorized code can execute, but the system complexity increases with multiple whitelist levels
Solution Approach 1:
The patent segments the whitelist architecture into multiple hierarchical levels (local whitelist, regional whitelist, global whitelist) that can be independently managed and updated. This segmentation maintains high security reliability by enforcing strict verification at each level while reducing overall system complexity through modular design, where each segment handles specific authorization scopes.
Solution Approach 2:
The patent implements a universal whitelist mechanism that operates across multiple code modules and execution contexts using the same cryptographic verification principles. This multi-functional approach maintains consistent security reliability across diverse scenarios while simplifying the system by reusing the same verification infrastructure rather than implementing separate mechanisms for each case.
4Reliability
If cryptographic hash verification is performed for each code module, then execution security is enhanced, but processing time increases
Solution Approach 1:
The patent performs cryptographic hash verification as a preliminary action before code execution is permitted. By completing the security verification in advance rather than during execution, the system ensures high execution security while minimizing time loss, as the verification occurs once before the code runs rather than repeatedly during runtime.
Solution Approach 2:
The patent uses cryptographic hash values as compact copies or representations of the entire code module's identity and integrity. Instead of verifying the full code module each time, the system verifies the small hash value copy, which maintains execution security while dramatically reducing verification time and processing requirements.
Applied Scientific Principles
This section explains which scientific principles are used to turn an abstract innovation direction into a practical engineering solution.
Function Achieved in This Case
This approach provides robust protection against unauthorized code execution, enhances malware detection, and enforces software licensing, significantly improving the security and management of computer systems by ensuring only approved code is executed.
Implementation Method 1
The content authenticator may be a cyptographically-secure hash value. In some embodiments, a hash algorithm such as secure hash algorithm 256 (SHA-256) may be utilized to generate a content authenticator.
Data Source
AI summary
Systems and methods are described for allowing the execution of authorized computer program code and for protecting computer systems and networks from unauthorized code execution. In one embodiment, a multi-level proactive whitelist approach is employed to secure a computer system by allowing only the execution of authorized computer program code thereby protecting the computer system against the execution of malicious code such as viruses, Trojan horses, spy-ware, and/or the like. Various embodiments use a kernel-level driver, which intercepts or “hooks” certain system Application Programming Interface (API) calls in order to monitor the creation of processes prior to code execution. The kernel-level driver may also intercept and monitor the loading of code modules by running processes, and the passing of non-executable code modules, such as script files, to approved or running code modules via command line options, for example. Once intercepted, a multi-level whitelist approach may be used to authorize the code execution.