Operating System Secure Boot With Pre-Execution Security Screening

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing secure boot technologies in UEFI firmware cannot ensure that an operating system is free from malware or security gaps, which can compromise the security of electronic devices during operation.

Innovation Solution

A method involving a series of software modules that execute trusted software code, check and assess security features using identification schemes and security guidelines, and execute subsequent modules only if they meet predefined trustworthiness thresholds, ensuring cryptographic integrity and identifying undesirable functions before execution.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If cryptographic signature checking is performed on starting components, then integrity of software modules is ensured, but security gaps or malware in the operating system cannot be detected

Engineering Contradiction:
Improveintegrity of software modulesVSAvoidsecurity gaps or malware
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent applies preliminary action by performing security feature assessment on the operating system kernel before it is fully executed. The first software module (UEFI firmware) analyzes security features of the second software module (OS kernel) during the boot process, before the kernel gains full system access. This allows potential malware or security gaps to be detected early, before they can compromise the system.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent segments the traditional monolithic secure boot process into distinct phases: cryptographic signature verification of individual components, followed by separate security feature assessment of the OS kernel. This segmentation allows the system to not only verify integrity but also evaluate whether the loaded OS contains undesirable security features or malware, addressing the limitation of conventional secure boot.

Inventive Principle:
Principle #1Segmentation

2Measurement precision

If traditional secure boot is used, then individual starting components are verified, but comprehensive security assessment of the operating system is not performed

Engineering Contradiction:
Improveverification of starting componentsVSAvoidsecurity assessment capability
Core Design Contradiction:
Measurement precisionVSDevice complexity

Solution Approach 1:

The patent implements multi-functionality by enabling the first software module to perform both cryptographic signature verification and security feature assessment functions. The UEFI firmware not only verifies the signature of the OS kernel but also executes security analysis to identify malware or security gaps, combining multiple security functions into a unified boot process.

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

Solution Approach 2:

The patent introduces an intermediary security assessment mechanism that operates between the traditional signature verification and the actual execution of the OS. The first software module acts as an intermediary that analyzes security features of the second software module before allowing it to run, providing an additional layer of security evaluation without requiring complete redesign of the secure boot architecture.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS12406065B2Method for securely starting device software, in particular an operating system, of an electronic device
Publication Date: 2025.09.02 SIEMENS AG
  • US12406065B2 patent drawing
  • US12406065B2 patent drawing
  • US12406065B2 patent drawing

AI summary

A method for securely starting device software is provided, in particular an operating system, of an electronic device, wherein a plurality of successive software modules which contain software code are run by the device. The method has the steps of: a) running the first software module, b) loading the subsequent software module using the preceding software module, c) checking the software code of the subsequent software module and identifying security features using an identification scheme, d) evaluating the identified security features using a security, e) running the subsequent software module if the evaluation results in a value of trustworthiness that lies above a specified threshold, and f) running steps b) to e) for each of the subsequent software modules.