Secure Hardware Attestation for Verified Software Stacks

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current software verification methods are computationally expensive and often unable to provide a complete formal verification of an entire system's software code, leading to incomplete security guarantees, as they rely on assumptions about the correctness of operating systems, libraries, and hardware.

Innovation Solution

The implementation of a system that verifies software at the assembly level, using secure hardware to execute fully verified software stacks, where credentials from both the software and hardware attest to their identities, ensuring end-to-end security through encrypted communication and secure boot processes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If software verification is performed at the assembly level using secure hardware, then security reliability is improved, but device complexity increases

Engineering Contradiction:
Improvesecurity reliabilityVSAvoiddevice complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent introduces secure hardware (Trusted Platform Module) as an intermediary that performs verification functions. The TPM acts as a mediator between the software system and external verifiers, handling cryptographic operations and attestation without requiring the main system to implement complex verification logic. This resolves the contradiction by offloading verification complexity to a dedicated security module while maintaining high security reliability.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The verification system is segmented into distinct components: the software system under verification, the secure hardware (TPM) for cryptographic operations, and external verifiers. This segmentation allows each component to specialize in specific functions, improving security reliability while distributing complexity across multiple manageable elements rather than concentrating it in a single complex system.

Inventive Principle:
Principle #1Segmentation

2Reliability

If the entire software stack is verified, then security assurance is improved, but verification time increases

Engineering Contradiction:
Improvesecurity assuranceVSAvoidverification time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements verified boot processes that perform verification during system initialization before the system becomes operational. By conducting verification in advance (during boot), the system ensures security assurance is established before use, while the verification process itself is optimized to complete within the boot time window, thus not adding significant loss of time to the overall system availability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The verification process uses optimized cryptographic operations and attestation protocols that enable rapid verification of the software stack. The TPM performs cryptographic hashing and signature verification in optimized sequences, allowing comprehensive verification of the entire software stack to occur quickly during boot, thereby maintaining security assurance while minimizing verification time impact.

Inventive Principle:
Principle #21Skipping (Rushing through)

Data Source

PatentEP3201822B1End-to-end security for hardware running verified software
Publication Date: 2022.05.25 MICROSOFT TECHNOLOGY LICENSING LLC
  • EP3201822B1 patent drawingFigure 1
  • EP3201822B1 patent drawingFigure 2
  • EP3201822B1 patent drawingFigure 3

AI summary

A verified software system may be executable on secure hardware. Prior to being executed, the software system may be verified as conforming to a software specification. First credentials attesting to an identity of the software system may be sent to an external application. Second credentials signed by a provider of the secure hardware may be sent to the external application. The second credentials may attest to an identity of the secure hardware. The external application may securely exchange one or more messages with a software application of the software system. For example, the one or more messages may be decryptable only by the external application and the software application to provide confidentiality for each message. As another example, an attestation may vouch for an identity of a sender of each of the one or more messages to attest to an integrity of each message.