Code Authentication via Digital Signatures and Hash Verification

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current operating systems lack consistent mechanisms for authenticating the identity of programs, which can lead to security issues due to unreliable identification methods that can be circumvented by modifications or alterations, and fail to account for changes in program behavior or location, especially when programs are updated or relocated.

Innovation Solution

A code authentication architecture that signs code with a digital signature, computes its validity, and verifies it against constraints using Application Programming Interfaces (APIs), allowing for reliable identification and detection of modifications, even if the code is updated or relocated, ensuring the code's integrity and authenticity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If stored paths or bundle identifiers are used to identify programs, then program identification is simplified, but the identification can be circumvented by copying or editing these identifiers

Engineering Contradiction:
Improveprogram identificationVSAvoididentification authenticity
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent applies preliminary action by computing and storing hash values of program code at the time of installation or distribution. This pre-computed hash serves as a baseline for future integrity checks, allowing the system to verify program authenticity without repeatedly analyzing the entire program code. The hash is calculated in advance and stored securely, enabling efficient later verification.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces hash values as an intermediary between the program code and the identification system. Instead of directly using mutable identifiers like bundle names or paths, the system uses hash values derived from the actual program code as the authentication intermediary. This hash acts as a fingerprint that binds the program's actual content to its identity, preventing circumvention through identifier copying or editing.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If Keychain layer with hash scheme is used to recognize trusted programs, then program authenticity is verified, but user intervention is required for every program update

Engineering Contradiction:
Improveprogram authenticity verificationVSAvoiduser intervention time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies dynamics by implementing a flexible verification system that adapts its behavior based on the situation. The system can operate in different modes: strict verification mode where hash mismatches require user intervention, and permissive mode where certain changes are automatically accepted. This dynamic approach allows the system to balance security with convenience, reducing unnecessary user interruptions while maintaining authenticity verification.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the verification parameter from requiring exact hash matches to allowing controlled deviations. By introducing parameters such as version tolerance thresholds and change type classifications, the system can determine whether a hash mismatch represents a legitimate update or a security threat. This parameter-based approach enables automatic handling of routine updates while maintaining security for significant changes.

Inventive Principle:
Principle #35Parameter changes

3Adaptability or versatility

If program relocation is allowed, then program flexibility is improved, but the stored path-based identification becomes invalid

Engineering Contradiction:
Improveprogram relocation capabilityVSAvoidprogram identity binding
Core Design Contradiction:
Adaptability or versatilityVSLoss of information

Solution Approach 1:

The patent applies copying by creating and storing a hash value copy of the program code at its original location. This hash copy travels with the program when it is relocated, serving as a portable authentication credential. Instead of relying on the program's location-specific path information, the system uses this copied hash value to verify the program's authenticity regardless of where it resides on the system.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent substitutes the mechanical path-based identification system with a hash-based verification system. The old system relied on physical location (file path) to identify programs, which breaks when programs are moved. The new system replaces this mechanical location-dependent approach with a content-based hash verification mechanism that works independently of program location, enabling relocation while maintaining identity binding.

Inventive Principle:
Principle #28Mechanics substitution (Replace mechanical system)

Data Source

PatentUS8782807B2System and method for authenticating code executing on computer system
Publication Date: 2014.07.15 APPLE INC
  • US8782807B2 patent drawing
  • US8782807B2 patent drawing
  • US8782807B2 patent drawing

AI summary

A code authentication architecture is used to sign code by adding one or more digital signatures to it. The digital signatures identify what authority signed the code, what the code contains, what type of program the code is, or other identifying information. When the signed code is later executed on a computer system, its identity is obtained by accessing encrypted information of the code stored on disk. The architecture then determines whether the identity satisfies at least one requirement imposed on the code for some purpose. If the code has been altered from when it was signed or it fails to satisfy a requirement imposed, the code will not have a valid identity. In addition to verifying the identity of the code, the architecture also validates executing code immediately responsible for managing the code and additional executing code in a chain of hosts responsible for managing one another.