VM Local Agent Attestation for Trusted Boot Configuration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing remote attestation mechanisms fail to prevent malicious modification of the configuration of a local agent in a virtual machine within a hardware-based Trusted Execution Environment, compromising data integrity and authenticity, and do not allow easy configuration changes by the virtual machine owner.

Innovation Solution

A method involving customization, signing, and insertion of cryptographic assets into immutable fields of the virtual machine configuration, followed by local verification and remote attestation report validation to ensure authenticity and integrity of the local agent configuration before booting, using AMD's SEV-SNP features.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If cryptographic assets are embedded in the virtual machine configuration to verify local agent authenticity, then configuration integrity is improved, but device complexity increases

Engineering Contradiction:
Improveconfiguration integrityVSAvoidverification mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The cryptographic assets are embedded in the virtual machine configuration during the VM launch phase, before the local agent executes. This preliminary embedding ensures that the verification mechanism is already in place and does not require complex runtime additions, thus improving reliability while managing complexity through advance preparation

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary verification process where the local agent proves possession of cryptographic assets through attestation reports, rather than directly verifying configurations. This intermediary mechanism simplifies the overall system by creating a trusted verification layer that manages the complexity of cryptographic verification

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If the local agent configuration is made immutable through cryptographic signing, then security is improved, but adaptability decreases

Engineering Contradiction:
ImprovesecurityVSAvoidconfiguration flexibility
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent creates a dynamic balance between immutability and adaptability by allowing cryptographic verification of the initial configuration while enabling controlled updates through the same verification mechanism. The configuration can be updated as long as the updates maintain cryptographic validity, thus achieving both security and flexibility through time-dependent adaptability

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent allows configuration parameters to be changed through controlled updates that are verified against the original cryptographic assets. By changing parameters through a verified update process rather than direct modification, the system maintains security while enabling necessary adaptability for different operational scenarios

Inventive Principle:
Principle #35Parameter changes

3Reliability

If remote attestation is implemented to verify TEE state, then trust verification is improved, but communication overhead increases

Engineering Contradiction:
Improvetrust verificationVSAvoidattestation communication time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts only the essential verification elements (cryptographic assets and their presence in attestation reports) from the full remote attestation process. By taking out only the critical verification components rather than implementing complete remote attestation, the system maintains trust verification while reducing communication overhead and time loss

Inventive Principle:
Principle #2Taking out (Extraction)

4Reliability

If cryptographic verification is performed before boot continuation, then system security is improved, but boot time increases

Engineering Contradiction:
Improvesystem securityVSAvoidboot time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The cryptographic verification is performed as a preliminary check during the early boot phase, before the system continues to full operation. By conducting verification preliminarily and integrating it into the boot sequence rather than as a separate post-boot step, the system ensures security while minimizing the impact on overall boot time through efficient timing

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP4679302A1Method for remotely verifying the configuration of a local agent of a virtual machine, executed within a hardware-based trusted execution environment, via a protocol including remote attestation
Publication Date: 2026.01.14 CYSEC SA
  • EP4679302A1 patent drawingFigure 1
  • EP4679302A1 patent drawingFigure 2
  • EP4679302A1 patent drawing

AI summary

A method for remotely verifying the configuration of a local agent (8) of a virtual machine (2), executed withing a hardware-based Trusted Execution Environment, via a protocol including remote attestation, the virtual machine (2) comprising said local agent (8) and being connected to a remote server (4) comprising a verifier (10), the method comprising: - customizing (100), at a remote server side, a predetermined configuration of the local agent (8); - signing (102), at the remote server side, said predetermined configuration of the local agent (8) with predetermined cryptographic assets; - receiving (104), at the verifier (10), said cryptographic assets; - remotely configuring (106), at a cloud side, the launch of the virtual machine (2) and inserting at least one of said cryptographic assets into attestable and immutable fields of a configuration of the virtual machine (2); - launching (108), at the cloud side, the boot of the virtual machine (2) by using said configuration of the virtual machine (2) and starting the local agent (8) by using said configuration of the local agent (8), - verifying (110), at a local agent (8) side and before continuing the boot process of the virtual machine (2), the authenticity and/or integrity of the configuration of the local agent (8) by using the at least one of said cryptographic assets of the attestable and immutable fields of the configuration of the virtual machine (2) to which it has access; - in case of valid verification of the authenticity and/or integrity of the configuration of the local agent (8), at the virtual machine (2) side and before continuing the boot process of the virtual machine (2), establishing (112) a communication channel (6) between the local agent (8) and the verifier (10) based on the said configuration of the local agent (8); - forwarding (114), at the virtual machine (2) side and before continuing the boot process of the virtual machine (2), to the verifier (10) an attestation report requested by the local agent (8); - comparing (116), at the verifier (10) side and before continuing the boot process of the virtual machine (2), values of said attestable and immutable fields of the attestation report wherein cryptographic assets have been inserted with the corresponding received cryptographic assets to check compliance.