Runtime Firmware Hash Verification for Manufacturing Malware Detection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing security technologies fail to detect and address security threats that originate from compromised firmware or software components during the manufacturing and assembly of computer systems, as they primarily focus on user-related activities and do not account for malware incorporated into hardware devices at the time of manufacturing.

Innovation Solution

A method that involves obtaining an executable file containing basic input-output system firmware and software component data at runtime, generating a hash value, and comparing it with a stored hash value from the build time to detect any modifications, ensuring the firmware and software match exactly as installed during manufacturing before allowing the hardware component to boot.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If hash value comparison is implemented to detect firmware modifications, then security against manufactured malware is improved, but device complexity increases

Engineering Contradiction:
ImprovesecurityVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent applies preliminary action by computing and storing hash values of firmware images during the manufacturing process before the device is deployed. This pre-computed reference hash is stored in secure memory, enabling later comparison without requiring complex real-time analysis of the entire firmware binary during runtime.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent replaces complex mechanical or manual firmware verification methods with a computational approach using hash value comparison. Instead of physically inspecting or manually verifying firmware integrity, the system uses cryptographic hash functions to generate and compare compact numerical representations, significantly simplifying the verification mechanism.

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

2Measurement precision

If firmware verification is performed at runtime, then detection precision is improved, but processing time increases

Engineering Contradiction:
Improvedetection precisionVSAvoidprocessing time
Core Design Contradiction:
Measurement precisionVSLoss of time

Solution Approach 1:

The patent extracts the essential verification information (hash value) from the complete firmware binary during manufacturing and stores it separately. At runtime, only this compact hash value needs to be computed and compared, rather than analyzing the entire firmware image, thus maintaining high detection precision while minimizing processing time.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent transforms the firmware verification problem from comparing entire binary files to comparing compact hash values. This parameter transformation changes the verification from a large-scale operation to a small-scale operation, dramatically reducing runtime processing requirements while preserving detection accuracy.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11537716B1Methods for detecting changes to a firmware and devices thereof
Publication Date: 2022.12.27 F5 NETWORKS INC
  • US11537716B1 patent drawing
  • US11537716B1 patent drawing
  • US11537716B1 patent drawing

AI summary

Methods, non-transitory computer readable media, network traffic manager apparatuses, and systems that assist with detecting changes to a firmware software components, and configuration parameters includes obtaining an executable file comprising a basic input-output system firmware and software component data of a hardware component at run-time. A hash value for the obtained executable file at the run-time is identified. The identified hash value is compared with a stored hash value associated with the obtained executable file to determine when the obtained executable file is unmodified, wherein the stored hash value was determined at a build time of the hardware component. The obtained executable file of the hardware component is executed when the obtained executable file is determined to be unmodified.