Kernel Whitelist Access Control for Tamper-Proof Data Protection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current data protection methods are inadequate in preventing data loss, destruction, or leakage from ransomware and manual sabotage, with existing antivirus solutions having limitations such as slow signature database updates, low recognition rates, and incomplete protection mechanisms.

Innovation Solution

A tamper-proof data protection method and system that operates in the computer system kernel, utilizing whitelists for paths and processes, and employs SSL encryption authentication to verify access permissions, ensuring only authorized processes can access protected data.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If antivirus solutions use signature-based detection and killing methods, then ransomware can be detected and killed, but the update speed of virus signature database is slow, recognition rate is low, and false killing occurs

Engineering Contradiction:
Improveransomware detection capabilityVSAvoidsignature database update speed
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The patent performs preliminary actions by establishing protection path whitelists and process whitelists before ransomware attacks occur. The system pre-configures allowed file paths and authorized process names, enabling proactive protection rather than reactive signature-based detection. This preliminary configuration allows the system to immediately block unauthorized access attempts without waiting for signature updates.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent inverts the traditional antivirus approach by using whitelist-based authorization instead of blacklist-based blocking. Rather than trying to identify and block all known malicious signatures, the system authorizes only specific paths and processes, automatically denying everything else. This inversion fundamentally changes the detection paradigm from signature-matching to permission-validation.

Inventive Principle:
Principle #13The other way round (Inversion)

2Reliability

If antivirus solutions use signature-based detection, then known ransomware can be identified, but recognition rate is low and false killing occurs

Engineering Contradiction:
Improveransomware recognition accuracyVSAvoiddetection mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent inverts the traditional antivirus approach by using whitelist-based authorization instead of blacklist-based blocking. Rather than trying to identify and block all known malicious signatures, the system authorizes only specific paths and processes, automatically denying everything else. This inversion fundamentally changes the detection paradigm from signature-matching to permission-validation.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The patent extracts the essential protective function from complex signature-matching mechanisms. By isolating the core requirement for data protection (authorization of access paths and processes), the system eliminates the need for maintaining large signature databases and complex pattern-matching algorithms, achieving high accuracy with simpler logic.

Inventive Principle:
Principle #2Taking out (Extraction)

3Reliability

If encryption methods are used to protect data, then data confidentiality is improved, but the check program for protecting data is not comprehensive enough against manual sabotage and misoperation

Engineering Contradiction:
Improvedata protection reliabilityVSAvoidprotection coverage scope
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent segments the protection mechanism into two independent but complementary components: protection path whitelists and process whitelists. This segmentation allows the system to independently control and verify both the location of protected data and the identity of authorized processes, creating comprehensive protection coverage that addresses both encryption limitations and manual sabotage risks.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces whitelist verification as an intermediary layer between the user and the data. This intermediary mechanism checks both the access path and process identity before allowing data operations, preventing both malicious attacks and accidental misoperations without requiring direct user intervention or complex encryption key management.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Reliability

If whitelist verification is implemented in the kernel, then comprehensive access control is achieved, but system complexity increases

Engineering Contradiction:
Improveaccess control securityVSAvoidkernel module complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent implements a universal whitelist verification mechanism in the kernel that handles multiple types of protected objects (files, directories, devices) through a single unified interface. The same verification logic applies to all object types, reducing kernel complexity while maintaining comprehensive security coverage across the entire system.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Data Source

PatentUS12511417B2Tamper-proof data protection method and system
Publication Date: 2025.12.30 EISOO SOFTWARE
  • US12511417B2 patent drawing
  • US12511417B2 patent drawing
  • US12511417B2 patent drawing

AI summary

A tamper-proof data protection method and system. The tamper-proof data protection method runs in a computer system kernel and includes the steps described below. In step 1, an access instruction for data is acquired, and the access instruction includes an access object path and access process information. In step 2, it is determined whether the access object path exists in a maintained protection path whitelist or in a subpath of a path in the protection path whitelist. If so, step 3 is executed; otherwise, a call permission signal is generated. In step 3, according to the access process information, it is determined whether the current access process exists in a maintained process whitelist. If so, a call permission signal is generated; and otherwise, an access denied signal is generated.