Integrity Checking Module for Closed Operating Systems

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Mobile devices with closed operating systems pose challenges in detecting integrity compromises due to restricted access to system information, making it difficult for third-party software to identify and prevent unauthorized access or malware, relying heavily on device providers for security.

Innovation Solution

Implementing an integrity checking module that defines preconfigured user and system portions on a closed operating system, allowing restricted access to system objects and attributes, performing baseline and integrity checks using predefined parameters, and generating reports to indicate potential compromises.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a closed operating system is used to restrict access to system information, then system security is improved, but the ability to detect integrity compromises deteriorates

Engineering Contradiction:

Improvesystem securityVSAvoidintegrity compromise detection

Core Design Contradiction:

ReliabilityVSDifficulty of detecting and measuring

Solution Approach 1:

The integrity checking module performs a baseline integrity check at predetermined times (e.g., device initialization, before/after operations) to establish expected values for system objects and attributes. This preliminary action creates a reference point for future comparisons, enabling detection of integrity compromises without requiring continuous real-time monitoring that would consume excessive resources.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The integrity checking module creates copies of system object information (file names, paths, attributes, metadata) and system attribute values (memory utilization, process lists) from the closed operating system. These copies are stored in a accessible format that can be compared against baseline values, allowing integrity verification without directly accessing restricted system memory or processes.

Inventive Principle:

Principle #26Copying

2Reliability

If third party software developers are given limited API access to system information, then system security is improved, but the capability to perform integrity checks deteriorates

Engineering Contradiction:

Improvesystem securityVSAvoidintegrity checking capability

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The integrity checking module is designed to check multiple types of system objects (files, folders, processes, memory, metadata) and system attributes (memory utilization, process lists, system configuration) through a unified interface. This multi-functional capability allows the same module to perform comprehensive integrity verification across diverse system components despite API limitations.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system checks integrity by comparing current values of system objects and attributes against baseline values established at predetermined times. By monitoring changes in parameters such as file attributes, metadata, memory utilization, and process lists, the module can detect integrity compromises without requiring direct access to restricted system areas.

Inventive Principle:

Principle #35Parameter changes

3Measurement precision

If comprehensive access to system objects and attributes is granted for integrity checking, then detection precision is improved, but system security deteriorates

Engineering Contradiction:

Improveintegrity detection precisionVSAvoidsystem security

Core Design Contradiction:

Measurement precisionVSReliability

Solution Approach 1:

The integrity checking module extracts only the specific information needed for integrity verification from the closed operating system, such as system object metadata, file attributes, and system attribute values. By extracting only necessary data rather than granting comprehensive access, the module achieves sufficient detection precision while maintaining system security restrictions.

Inventive Principle:

Principle #2Taking out (Extraction)

Solution Approach 2:

The integrity checking module acts as an intermediary between the security requirements and the integrity verification needs. It obtains information from system objects and attributes through permitted API calls, processes this information to assess integrity, and generates reports without requiring direct or comprehensive access to restricted system areas. This intermediary role enables precision while preserving security.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentUS10430592B2Integrity checking for computing devices

Publication Date: 2019.10.01 FEDERAL RESERVE BANK OF PHILADELPHIA

AI summary

A computing device may perform integrity checks on a closed operating system defining a preconfigured user portion and a preconfigured system portion using an integrity checking module. The integrity checking module may access parameters associated with an object stored on the system portion of the operating system. Files on the system portion may be accessed by submitting a query that comprises a file name, a file directory, and at least one parameter to the system portion of the operating system. The integrity checking module may provide an indication of a potential compromise to the integrity of the computing device based on the integrity check. The integrity check may be performed periodically and/or aperiodically. Updated integrity values may be compared against previously determined integrity values to update the integrity check. The integrity checking module may perform the integrity check using a signature function or hashing function to generate the integrity values.