Hypervisor Bundle Signing With Trusted Certificate Injection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Users desire to add custom binaries and configurations to a hypervisor while maintaining security features that prevent execution of unsigned binaries and configurations, but existing hypervisor security measures restrict such customizations.
Innovation Solution
A method involving the use of self-signed digital certificates and public-private key pairs to verify and install custom software installation bundles (SIBs) in a hypervisor, allowing the hypervisor to trust and execute user-created SIBs by appending vendor-trusted certificates to its key store.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the hypervisor enforces security features to prevent execution of unsigned binaries and scripts, then system security is improved, but user ability to install custom software installation bundles (SIBs) is restricted
Solution Approach 1:
The hypervisor performs preliminary verification of digital signatures on SIBs before allowing installation. By checking the digital signature in advance, the system ensures that only authenticated and authorized custom software can be installed, thus maintaining security while enabling customization.
Solution Approach 2:
Digital certificates act as an intermediary mechanism between the user's custom SIBs and the hypervisor's security requirements. The certificate-based authentication system mediates the trust relationship, allowing the hypervisor to verify the authenticity of unsigned binaries through cryptographic proof rather than direct execution restrictions.
2Object-affected harmful factors
If the hypervisor prevents execution of binaries from unsigned SIBs, then execution of malicious code is blocked, but legitimate custom binaries cannot be executed
Solution Approach 1:
The patent replaces the mechanical restriction mechanism (blocking execution of all unsigned binaries) with a cryptographic verification mechanism. Instead of physically preventing execution, the system uses digital signature verification to distinguish between malicious and legitimate custom binaries, allowing authenticated custom code to execute while blocking unauthorized code.
3Stability of the object's composition
If the hypervisor restricts post-boot configurations, then system stability is maintained, but user-desired custom configurations cannot be applied
Solution Approach 1:
The hypervisor performs preliminary verification of digital signatures on configuration files before applying post-boot configurations. By validating the authenticity of configuration files in advance through digital signature verification, the system ensures that only authorized configurations are applied, maintaining stability while enabling legitimate custom configurations.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An example method of installing a first software installation bundle (SIB) in a hypervisor of a computer includes: receiving, by the hypervisor, the first SIB, the first SIB having a first digital signature created using a first public-private key pair and a first certificate created using the first public-private key pair; receiving, by the hypervisor, a second SIB, the second SIB having a payload being the first certificate, the second SIB having a second digital signature created using a second public-private key pair and a second certificate created using the second public-private key pair; installing, by the hypervisor, the second SIB by verifying the second digital signature and adding the first certificate to a key store of the hypervisor; and installing, by the hypervisor, the first SIB by verifying trust of the first certificate in the key store and verifying the first digital signature.