File Trust Determination via Dominant Developer Identification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current computer security methods, including signature-based and heuristic approaches, fail to effectively classify trusted applications and files, leading to false positives and delayed detection of malicious software, especially for new or less frequently used files, due to the inefficiencies in cloud-based reputation services.

Innovation Solution

A method and system that determine the trust level of a file by identifying a dominant developer through stable file names and private key signatures, using verdicts from outside services to classify files without the need for extensive code analysis or uploading large amounts of data to cloud infrastructures, thereby reducing false positives and improving the classification of new versions of trusted applications.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If cloud-based reputation services are used to detect malicious software, then the speed of response and level of protection improve, but the complexity of the system increases and large amounts of data must be uploaded to cloud infrastructures

Engineering Contradiction:
Improvedetection accuracyVSAvoidsystem complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary mechanism that aggregates files from multiple sources and determines trust levels based on dominant developers before uploading to cloud infrastructure. This intermediary layer reduces the complexity of direct cloud-based analysis by pre-processing and filtering data locally.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The system segments the trust determination process into distinct components: file aggregation, dominant developer identification, verdict collection from outside services, and trust level determination. This segmentation allows each component to be optimized independently, reducing overall system complexity.

Inventive Principle:
Principle #1Segmentation

2Reliability

If cloud-based reputation services analyze all uploaded files, then detection accuracy improves, but the time required for analysis increases and processing speed decreases

Engineering Contradiction:
Improveclassification accuracyVSAvoidanalysis time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

Instead of analyzing all uploaded files in the cloud, the system performs partial analysis locally by determining trust levels based on dominant developers and outside service verdicts before cloud upload. This partial action reduces analysis time while maintaining sufficient accuracy for trusted files.

Inventive Principle:
Principle #16Partial or excessive action

Solution Approach 2:

The system performs preliminary trust level determination locally using dominant developer identification and outside service verdicts before files are uploaded to cloud infrastructure. This preliminary action filters out obviously trusted files, reducing the workload and time required for subsequent cloud-based analysis.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If extensive code analysis is performed on all files, then detection accuracy improves, but the computational resources and processing time required increase significantly

Engineering Contradiction:
Improvedetection accuracyVSAvoidcomputational resources
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent extracts the essential trust determination factors (dominant developer identification, outside service verdicts, file groupings) from the full code analysis process. By taking out only the critical elements needed for trust assessment, the system reduces computational resource consumption while maintaining detection accuracy for trusted files.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

Instead of performing extensive code analysis on all files, the system uses copies of trust information from outside services and dominant developer verdicts. These copied trust indicators provide sufficient information for classification without requiring resource-intensive original code analysis.

Inventive Principle:
Principle #26Copying

4Reliability

If signature-based methods are used to detect malicious software, then detection accuracy improves for known threats, but the time delay for updating signature databases increases and new threats are not detected promptly

Engineering Contradiction:
Improvedetection accuracyVSAvoidupdate delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system enables self-service trust determination by using dominant developer identification and outside service verdicts that do not require centralized signature database updates. Each system can independently determine trust levels based on available information, eliminating the time delay associated with centralized signature distribution.

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3758330B1System and method of determining a trust level of a file
Publication Date: 2024.06.26 AO KASPERSKY LAB
  • EP3758330B1 patent drawingFigure 1
  • EP3758330B1 patent drawingFigure 2
  • EP3758330B1 patent drawingFigure 3

AI summary

Disclosed herein are systems and methods for determining trust levels of files on a computing device. In one example, an exemplary method comprises, selecting file names which are stable, generating at least one group of files from at least two files of the selected file names, the at least two files being components of a same application, searching for a presence of a dominant developer such that at least one private key of the dominant developer has been used to sign at least one file of the group of files that is generated, when a dominant developer is found, determining a trust level for all files of the group in accordance with verdicts associated with the dominant developer, and when the dominant developer is not found, determining the trust level for all the files of the group based on verdicts of outside services that have been assigned to the files of the group.