Control Flow Integrity Attestation Without Trusted Execution Environment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current methods for attesting Control Flow Integrity (CFI) of applications are complex and vulnerable to hardware-related attacks, such as Spectre and Meltdown, and require a Trusted Execution Environment (TEE) configuration, which is not always feasible.

Innovation Solution

A computer-implemented method generates asymmetric key pairs based on the executing code and a device key unique to the end entity, creating verifiable attestation claims without needing a TEE configuration, using existing hardware blocks for a lightweight and secure signing service.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a Trusted Execution Environment (TEE) is used to attest CFI, then the security and integrity of the application can be verified, but the device complexity increases and requires additional hardware configuration

Engineering Contradiction:
ImproveCFI attestation securityVSAvoidTEE configuration requirement
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent extracts the CFI attestation function from the TEE and implements it using standard hardware blocks (hash function, key pair generation, signature generation) that are already present in the device. This eliminates the need for special TEE configuration while maintaining security through the use of existing cryptographic hardware components.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent makes the existing hardware blocks serve multiple functions: the hash function block not only computes hashes but also forms the basis for key pair generation and signature verification. This multi-functionality eliminates the need for dedicated TEE hardware while maintaining the security requirements for CFI attestation.

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

2Reliability

If vendor countermeasures against tampering are used, then CFI protection is provided, but the system becomes vulnerable to hardware-related attacks like Spectre and Meltdown

Engineering Contradiction:
ImproveCFI protectionVSAvoidhardware vulnerability to Spectre and Meltdown
Core Design Contradiction:
ReliabilityVSObject-affected harmful factors

Solution Approach 1:

The patent replaces the traditional software-based CFI protection mechanisms with a hardware-based cryptographic approach. By using hardware hash function blocks and cryptographic key pair generation to create and verify signatures of execution traces, the system achieves CFI protection that is resistant to Spectre and Meltdown attacks, as these attacks target software-based mitigation strategies.

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

3Ease of manufacture

If a lightweight signing service using existing hardware blocks is implemented, then cost efficiency is improved, but the security strength may be reduced

Engineering Contradiction:
Improvecost efficiencyVSAvoidsecurity strength
Core Design Contradiction:
Ease of manufactureVSReliability

Solution Approach 1:

The patent changes the parameters of the existing hardware blocks to serve cryptographic purposes. By configuring the hash function block with specific parameters and using it in conjunction with key pair generation and signature verification, the system achieves security strength comparable to more expensive dedicated security hardware, while maintaining cost efficiency through the use of existing blocks.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS11777717B2Method for end entity attestation
Publication Date: 2023.10.03 HUAWEI TECH CO LTD
  • US11777717B2 patent drawing
  • US11777717B2 patent drawing
  • US11777717B2 patent drawing

AI summary

A method for attestation of Control Flow Integrity (CFI) of an application running on an end entity whereby an asymmetric key pair is generated by a Key Management Module (KMM) comprising a private key and a public key, then the public key is signed with a device key unique to the end entity thereby generating a public key certificate which attests to the private key being in possession of the end entity. The asymmetric key pair is based on the executing code of the application and the device key. The attestation claims regarding CFI of the application are signed by the private key in a dedicated signature module.