Generic Pre-OS Cryptographic Device Protocol

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

The pre-OS environment lacks flexibility in utilizing cryptographic devices due to the need for specific code to interact with each device, limiting the ability to leverage extended drivers and APIs provided by EFI firmware, which is undesirable for maintaining stable code during OS boot.

Innovation Solution

A generic cryptographic device protocol is introduced, allowing pre-OS applications to communicate with various cryptographic devices using a unified interface independent of device types and algorithms, eliminating the need for device-specific code by employing unique device and key identifiers.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional BIOS firmware is used in the pre-OS environment, then the system maintains simplicity with a monolithic binary structure, but the flexibility to utilize various cryptographic devices and drivers is lost

Engineering Contradiction:

Improveflexibility to utilize cryptographic devicesVSAvoidfirmware structure complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent segments the firmware structure by introducing a driver framework that separates cryptographic device drivers from the core BIOS firmware. This allows the firmware to load and manage multiple independent driver modules, each handling specific cryptographic devices, thereby improving adaptability without compromising the core firmware's simplicity.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The patent implements a universal driver framework that can interface with multiple types of cryptographic devices through a common API. This multi-functional approach allows a single firmware structure to support diverse cryptographic devices (TPM, HSM, smart cards, etc.) without requiring device-specific firmware implementations.

Inventive Principle:

Principle #6Universality (Multi-functionality)

2Ease of operation

If device-specific code is included in pre-OS applications to interact with cryptographic devices, then communication with each device type is enabled, but the code complexity and maintenance difficulty increase significantly

Engineering Contradiction:

Improveease of cryptographic device communicationVSAvoidpre-OS application code complexity

Core Design Contradiction:

Ease of operationVSDevice complexity

Solution Approach 1:

The patent introduces a driver framework as an intermediary layer between pre-OS applications and cryptographic devices. This mediator provides standardized interfaces and abstraction, allowing applications to communicate with any cryptographic device through uniform APIs without needing device-specific code, thereby simplifying application development and maintenance.

Inventive Principle:

Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent employs parameter-based device identification and configuration mechanisms where cryptographic devices are characterized by standardized parameters and attributes. The driver framework dynamically adapts to different devices by reading and configuring these parameters, eliminating the need for hard-coded device-specific logic in pre-OS applications.

Inventive Principle:

Principle #35Parameter changes

3Adaptability or versatility

If multiple cryptographic device drivers are supported in the pre-OS environment, then the versatility of cryptographic functionality is improved, but the system stability during boot process may be compromised

Engineering Contradiction:

Improvecryptographic device compatibilityVSAvoidsystem stability during boot

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent implements preliminary driver loading and initialization mechanisms where cryptographic device drivers are loaded and validated before the pre-OS applications execute. This preliminary action ensures that drivers are properly configured and tested ahead of time, preventing runtime errors that could compromise system stability during the critical boot process.

Inventive Principle:

Principle #10Preliminary action

Solution Approach 2:

The patent incorporates error handling and fallback mechanisms that cushion against potential driver failures. If a cryptographic device driver encounters an error or is incompatible, the system can gracefully handle the situation without crashing the entire boot process, thereby maintaining system stability while still supporting multiple device types.

Inventive Principle:

Principle #11Beforehand cushioning (Prior cushioning)

Data Source

PatentUS7836309B2Generic extensible pre-operating system cryptographic infrastructure

Publication Date: 2010.11.16 MICROSOFT TECHNOLOGY LICENSING LLC

AI summary

A cryptographic device protocol provides a generic interface allowing pre-OS applications to employ any of a variety of cryptographic devices within the pre-OS environment. The generic interface can be used independent of the specific cryptographic devices and is independent of the cryptographic or hashing algorithms used by each device. Cryptographic functions may be performed in the pre-OS environment by pre-OS applications communicating with cryptographic device drivers using the cryptographic device protocol that is independent of the cryptographic devices. Each cryptographic device may be identified by a unique device identifier and may have a number of keys available to it, with each key being identified by a unique key identifier.